Java Doc for jdbcResultSetMetaData.java in  » Database-DBMS » hsql » org » hsqldb » jdbc » Java Source Code / Java DocumentationJava Source Code and Java Documentation

 ResultSet rs = stmt.executeQuery("SELECT a, b, c FROM TABLE2");
 ResultSetMetaData rsmd = rs.getMetaData();
 int numberOfColumns = rsmd.getColumnCount();
 boolean b = rsmd.isSearchable(1);
 

HSQLDB-Specific Information:

HSQLDB supports a subset of the ResultSetMetaData interface.

The JDBC specification for ResultSetMetaData is in part very vague. This causes potential incompatibility between interpretations of the specification as realized in different JDBC driver implementations. As such, deciding to what degree reporting ResultSetMetaData is accurate has been considered very carefully. Hopefully, the design decisions made in light of these considerations have yeilded precisely the subset of full ResultSetMetaData support that is most commonly needed and that is most important, while also providing, under the most common use-cases, the fastest access with the least overhead and the best comprimise between speed, accuracy, jar-foootprint and retention of JDBC resources.

(fredt@users)
(boucherb@users)

HSQLDB-Specific Information:

Up to and including 1.7.1, HSQLDB did not report this value accurately.

Starting with HSQLDB 1.7.2, this feature is better supported.

HSQLDB-Specific Information:

Up to and including 1.7.1, HSQLDB did not support the notion of catalog and this method always returned "".

Starting with 1.7.2, HSQLDB supports catalog reporting only as an optional, experimental feature that is disabled by default. Enabling this feature requires setting the database property "hsqldb.catalogs=true". When enabled, the catalog name for table columns is reported as the name by which the hosting Database knows itself.

HSQLDB does not yet support any use of catalog qualification in DLL or DML. This fact is accurately indicated in the corresponding DatabaseMetaData.supportsXXX() method return values.

Regardless, reporting is done only in system table content and is not yet carried over to ResultSetMetaData.

For greater detail, see discussion at: jdbcDatabaseMetaData .

HSQLDB-Specific Information:

HSQLDB 1.7.1 did not support this feature; calling this method always caused an SQLException to be thrown, stating that the function was not supported.

HSQLDB-Specific Information:

Up to and including HSQLDB 1.7.1, this method always returned 0, which was intended to convey unknown display size. Unfortunately, this value is not universally handled by all clients and in the worst case can cause some applications to crash.

Starting with 1.7.2, this feature is better supported.

The current calculation follows these rules:

1. Long character types and datetime types:

   The maximum length/precision, repectively.

2. CHAR and VARCHAR types:
   • If the result set column is a direct pass through of a table column value, column size was declared and the connection is to an embedded database instance, then the declared value is returned.

   • Otherwise, the value of the system property hsqldb.max_xxxchar_display_size or the magic value 32766 (0x7FFE) (tested usable/accepted by most tools and compatible with assumptions made by java.io read/write UTF) when the system property is not defined or is not accessible, due to security constraints.

   It must be noted that the latter value in no way affects the ability of the HSQLDB JDBC driver to retrieve longer values and serves only as the current best effort at providing a value that maximizes usability across a wide range of tools, given that the HSQLDB database engine does not require the length to be declared and does not necessarily enforce it, even if declared.

3. Number types:

   The max precision, plus the length of the negation character (1), plus (if applicable) the maximum number of characters that may occupy the exponent character sequence. Note that some legacy tools do not correctly handle BIGINT values of greater than 18 digits.

4. BOOLEAN (BIT) type:

   The length of the character sequence "false" (5), the longer of the two boolean value String representations.

5. Remaining types:

   The maximum length/precision, respectively, as reported by DatabaseMetaData.getTypeInfo(), when applicable. If the maximum display size is unknown, unknowable or inapplicable, then zero is returned.

HSQLDB-Specific Information:

In HSQLDB a ResultSet column label is determined in the following order of precedence:

1. The label (alias) specified in the generating query.
2. The name of the underlying column, if no label is specified.
   This also applies to aggregate functions.
3. An empty String.

HSQLDB-Specific Information:

In HSQLDB a ResultSet column name is determined in the following order of prcedence:

1. The name of the underlying columnm, if the ResultSet column represents a column in a table.
2. The label or alias specified in the generating query.
3. An empty String.

If the jdbc.get_column_name property of the database has been set to false, this method returns the same value as jdbcResultSetMetaData.getColumnLabel(int) .

HSQLDB-Specific Information:

This reports the SQL type of the column. HSQLDB can return Objects in any Java integral type wider than Integer for an SQL integral type.

HSQLDB-Specific Information:

Starting with 1.8.0, HSQLDB reports the the declared length or precision specifiers for table columns (if they are defined, which up to 1.7.2 is not a requirement in DDL), as these values may or may not be enforced, depending on the value of the database property:

 sql.enforce_strict_size
 

Because the property may change from one instantiation of a Database to the next and because, when set true, is not applied to existing values in table columns (only to new values introduced by following inserts and updates), the length and/or precision specifiers for table columns still do not neccessarily accurately reflect true constraints upon the contents of the columns. This situation may or may not change in a future release.

HSQLDB-Specific Information:

Starting with 1.8.0, HSQLDB reports the declared scale for table columns depending on the value of the database property:

 sql.enforce_strict_size
 

HSQLDB-Specific Information:

Up to 1.7.1, HSQLDB did not support the notion of schemas at all, including schema names in result set metadata; this method always returned "".

Staring with 1.7.2, schema name reporting is supported only as an optional, experimental feature that is disabled by default. Enabling this feature requires setting the database property "hsqldb.schemas=true".

Specifically, when this feature is enabled under 1.7.2, only very limited support is provided by the engine for executing SQL containing schema-qualified database object identifiers. That is, when this feature is enabled under 1.7.2, it is not yet possible in most cases to use what would otherwise be the correct, canonical SQL calculated from ResultSetMetaData.

Regardless, reporting is done only in system table content and is not yet carried over to ResultSetMetaData.

For greater detail, see discussion at: jdbcDatabaseMetaData .

HSQLDB-Specific Information:

HSQLDB 1.7.1 did not report this value accurately, either always throwing or always returning false, depending upon client property values.

Starting with HSQLDB 1.7.2, this feature is better supported.

---

However, it must be stated here that, contrary to the generic documentation above, HSQLDB automatically numbered columns (IDENTITY columns, in HSQLDB parlance) are not read-only.

In fact, the generic documentation above seems to contradict the general definition of what, at minimum, an auto-increment column is:

Simply, an auto-increment column is one that guarantees it has a unique value after a successful insert or update operation, even if no value is supplied or NULL is explicitly specified by the application or a default value expression.

Further, without SQL Feature T176, Sequence generator support, the attributes of the internal source consulted for unique values are not defined. That is, unlike for a standard SQL SEQUENCE object or a system with full SQL 9x or 200n support for SQL Feature T174, Identity columns, an application must not assume and cannot determine in a standard way that auto-increment values start at any particular point, increment by any particular value or have any of the other attributes generally associated with SQL SEQUENCE generators. Further still, without full support for both feature T174 and T176, if a unique value is supplied by an application or provided by a declared or implicit default value expression, then whether that value is used or substituted with one from the automatic unique value source is implementation-defined and cannot be known in a standard way. Finally, without full support for features T174 and T176, it is also implementation-defined and cannot be know in a standard way whether an exception is thrown or a unique value is automatically substituted when an application or default value expression supplies a non-NULL, non-unique value.

Up to and including HSQLDB 1.7.2, values supplied by an application or default value expression are used if they are indeed non-NULL unique values, while an exception is thrown if either possible value source for the site attempts to supply a non-NULL, non-unique value. This is very likely to remain the behaviour of HSQLDB for its foreseable lifetime and at the very least for the duration of the 1.7.x release series.

---

Regardless of the new and better support for reporting isAutoIncrement(), it is still possible under certain conditions that accurate reporting may be impossible. For example, if this object's parent Connection is closed before the first call to this method or to any other method of this class that initializes the connection-dependent ResultSetMetaData values, then it is impossible to report accurately for result set columns that directly represent table column values.

Under such special circumstances, the driver rethrows the exception that occured during the initialization, or a SQLException wrapping it.

Those wishing to determine the auto-increment status of a table column in isolation from ResultSetMetaData can do so by inspecting the corresponding value of the SYSTEM_COLUMNS.IS_IDENTITY BOOLEAN column which is also currently included (in a fashion proprietary to HSQLDB) as the last column of the jdbcDatabaseMetaData.getColumns() result.

HSQLDB-Specific Information:

HSQLDB 1.7.1 did not report this value accurately.

Starting with 1.7.2, this feature is better supported.

This method returns true for any column whose data type is a character type, with the exception of VARCHAR_IGNORECASE for which it returns false. It also returns false for any column whose data type is a not a character data type.

HSQLDB-Specific Information:

Up to and including HSQLDB 1.7.2, this method always returns false.

This is because true fixed (precision,scale) data types are not yet supported. That is, DECIMAL and NUMERIC types are implemented as a thin wrap of java.math.BigDecimal, which cannot, without additional, as yet unimplemented constraint enforcement code, be said to be a fixed (precision,scale) types.

HSQLDB-Specific Information:

HSQLDB 1.7.1 did not report this value accurately.

Starting with HSQLDB 1.7.2, this method always returns false. The reason for this is that it is generally either very complex or simply impossible to calculate deterministically true for table columns under all concievable conditions. The value is of dubious usefulness, except perhaps if there were support for updateable result sets using "SELECT ... FOR UPDATE" style locking. However, this is not anticipated to occur any time in the 1.7.x release series.

HSQLDB-Specific Information:

Up to 1.7.1, HSQLDB did not report this value accurately.

Starting with 1.7.2, this feature is better supported.

columnNullableUnknown is always returned for result set columns that do not directly represent table column values (i.e. are calculated), while the corresponding value in SYSTEM_COLUMNS.NULLABLE is returned for result set columns that do directly represent table column values.

Those wishing to determine the nullable status of a table column in isolation from ResultSetMetaData and in a DBMS-independent fashion can do so by calling DatabaseMetaData.getColumns() with the appropriate filter values and inspecting the result at the position described in the API documentation.

HSQLDB-Specific Information:

Up to and including 1.7.1, HSQLDB did not report this value accurately.

Starting with HSQLDB 1.7.2, this feature is better supported.

For result set columns that do not directly represent table column values (i.e. are calculated), true is reported. Otherwise, the read only status of the table and the database are used in the calculation, but not the read-only status of the session.

HSQLDB-Specific Information:

HSQLDB 1.7.1 did not report this value accurately.

Starting with 1.7.2, this feature is better supported.

If the data type of the column is definitely known to be searchable in any way under HSQLDB, then true is returned, else false. That is, if the type is reported in DatabaseMetaData.getTypeInfo() as having DatabaseMetaData.typePredNone or is not reported, then false is returned, else true.

HSQLDB-Specific Information:

HSQLDB 1.7.1 introduced support for this feature and 1.7.2 reports identical values (although using a slightly different implementation).

HSQLDB-Specific Information:

Up to and including 1.7.1, HSQLDB did not report this value accurately.

Starting with HSQLDB 1.7.2, this feature is better supported.

In essense, the negation of isReadOnly() is reported.