H2Dialect

Does the LIMIT clause come at the start of the SELECT statement, rather than at the end?

ANSI SQL defines the LIMIT clause to be in the form LIMIT offset, limit. Does this dialect require us to bind the parameters in reverse order?

For the underlying database, is READ_COMMITTED isolation implemented by forcing readers to wait for write locks to be released?

Do we need to drop the temporary table after use?

The syntax used to add a column to a table (optional).

Typically dialects which support sequences can create a sequence with a single command. This is convenience form of getCreateSequenceStrings(String) to help facilitate that.

Dialects which support sequences and can create a sequence in a single command need *only* override this method. Dialects which support sequences but require multiple commands to create a sequence should instead override getCreateSequenceStrings(String).

Command used to create a temporary table.

Retrieve the command used to retrieve the current timestamp from the database.

Typically dialects which support sequences can drop a sequence with a single command. This is convenience form of getDropSequenceStrings(String) to help facilitate that.

Dialects which support sequences and can drop a sequence in a single command need *only* override this method. Dialects which support sequences but require multiple commands to drop a sequence should instead override getDropSequenceStrings(String).

Get the string to append to SELECT statements to acquire locks for this dialect.

The syntax used during DDL to define a column as being an IDENTITY.

The keyword used to insert a generated value into an identity column (or null). Need if the dialect does not support inserts that specify no column values.

Get the select command to use to retrieve the last generated IDENTITY value.

Apply s limit clause to the query.

Typically dialects utilize variable limit clauses when they support limits. Thus, when building the select command we do not actually need to know the limit or the offest since we will just be using placeholders.

Here we do still pass along whether or not an offset was specified so that dialects not supporting offsets can generate proper exceptions. In general, dialects will override one or the other of this method and getLimitString(String, int, int).

Get the select command used retrieve the names of all sequences.

Generate the select expression fragment that will retrieve the next value of a sequence as part of another (typically DML) statement.

This differs from getSequenceNextValString(String) in that this should return an expression usable within another statement.

Generate the appropriate select statement to to retrieve the next value of a sequence.

This should be a "stand alone" select statement.

Should the value returned by getCurrentTimestampSelectString() be treated as callable. Typically this indicates that JDBC escape syntax is being used...

Does the dialect require that temporary table DDL statements occur in isolation from other statements? This would be the case if the creation would cause any current transaction to get committed implicitly.

JDBC defines a standard way to query for this information via the dataDefinitionCausesTransactionCommit() method. However, that does not distinguish between temporary table DDL and other forms of DDL; MySQL, for example, reports DDL causing a transaction commit via its driver, even though that is not the case for temporary table DDL.

Possible return values and their meanings:

• TRUE - Unequivocally, perform the temporary table DDL in isolation.
• FALSE - Unequivocally, do not perform the temporary table DDL in isolation.
• null - defer to the JDBC driver response in regards to dataDefinitionCausesTransactionCommit()

Does this dialect support a way to retrieve the database's current timestamp value?

Does this dialect support identity column key generation?

Does this dialect support some form of limiting query results via a SQL clause?

Does the dialect support propagating changes to LOB values back to the database? Talking about mutating the internal value of the locator as opposed to supplying a new locator instance...

For BLOBs, the internal value might be changed by: setBinaryStream(long), setBytes(long, byte[]), setBytes(long, byte[], int, int), or truncate(long).

For CLOBs, the internal value might be changed by: setAsciiStream(long), setCharacterStream(long), setString(long, String), setString(long, String, int, int), or truncate(long).

NOTE : I do not know the correct answer currently for databases which (1) are not part of the cruise control process or (2) do not supportsExpectedLobUsagePattern().

Does this dialect support "pooled" sequences. Not aware of a better name for this. Essentially can we specify the initial and increment values?

Does this dialect support sequences?

Does this dialect support temporary tables?

Does this dialect support `count(distinct a,b)`?

Does this dialect support UNION ALL, which is generally a faster variant of UNION?

Does this dialect support the UNIQUE column syntax?