DB2Dialect

DB2 does have a one-based offset, however this was actually already handled in the limit string building (the '?+1' bit). To not mess up inheritors, I'll leave that part alone and not touch the offset here.

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 constraints before dropping tables in this dialect?

Generate a temporary table name given the base table.

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).

Get any fragments needing to be postfixed to the command for temporary table creation.

Command used to create a temporary table.

Get the separator to use for defining cross joins when translating HQL queries.

Typically this will be either [ cross join ] or [, ]

Note that the spaces are important!

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).

The name of the SQL function that transforms a string to lowercase

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

Given a callable statement previously processed by registerResultSetOutParameter(CallableStatement, int), extract the ResultSet from the OUT parameter.

Given a java.sql.Types type code, determine an appropriate null value to use in a select clause.

One thing to consider here is that certain databases might require proper casting for the nulls here since the select here will be part of a UNION/UNION ALL.

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...

Registers an OUT parameter which will be returning a ResultSet. How this is accomplished varies greatly from DB to DB, hence its inclusion (along with getResultSet(CallableStatement)) here.

DB2 in fact does require that parameters appearing in the select clause be wrapped in cast() calls to tell the DB parser the type of the select value.

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

Does this dialect support empty IN lists?

For example, is [where XYZ in ()] a supported construct?

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 FOR UPDATE in conjunction with outer joined rows?

Does this dialect support parameters within the SELECT clause of INSERT ... SELECT ... statements?

DB2 is know to support parameters in the SELECT clause, but only in casted form (see requiresCastingOfParametersInSelectClause()).

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 asking the result set its positioning information on forward only cursors. Specifically, in the case of scrolling fetches, Hibernate needs to use isAfterLast() and isBeforeFirst(). Certain drivers do not allow access to these methods for forward only cursors.

NOTE : this is highly driver dependent!

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 the LIMIT clause take a "maximum" row number instead of a total number of returned rows?

This is easiest understood via an example. Consider you have a table with 20 rows, but you only want to retrieve rows number 11 through 20. Generally, a limit with offset would say that the offset = 11 and the limit = 10 (we only want 10 rows at a time); this is specifying the total number of returned rows. Some dialects require that we instead specify offset = 11 and limit = 20, where 20 is the "last" row we want relative to offset (i.e. total number of rows = 20 - 11 = 9)

So essentially, is limit relative from offset? Or is limit absolute?