| Method from org.hibernate.dialect.Dialect Detail: |
|---|
 public String appendIdentitySelectToInsert(String insertString) {
return insertString;
}
|
public String appendLockHint(LockMode mode,
String tableName) {
return tableName;
} Some dialects support an alternative means to SELECT FOR UPDATE,
whereby a "lock hint" is appends to the table name in the from clause.
contributed by Helge Schulz |
public String applyLocksToSql(String sql,
Map aliasedLockModes,
Map keyColumnNames) {
return sql + new ForUpdateFragment( this, aliasedLockModes, keyColumnNames ).toFragmentString();
} Modifies the given SQL by applying the appropriate updates for the specified
lock modes and key columns.
The behavior here is that of an ANSI SQL SELECT FOR UPDATE. This
method is really intended to allow dialects which do not support
SELECT FOR UPDATE to achieve this in their own fashion. |
public boolean areStringComparisonsCaseInsensitive() {
return false;
} Are string comparisons implicitly case insensitive.
In other words, does [where 'XYZ' = 'xyz'] resolve to true? |
public boolean bindLimitParametersFirst() {
return false;
} Does the LIMIT clause come at the start of the
SELECT statement, rather than at the end? |
public boolean bindLimitParametersInReverseOrder() {
return false;
} 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? |
public SQLExceptionConverter buildSQLExceptionConverter() {
// The default SQLExceptionConverter for all dialects is based on SQLState
// since SQLErrorCode is extremely vendor-specific. Specific Dialects
// may override to return whatever is most appropriate for that vendor.
return new SQLStateConverter( getViolatedConstraintNameExtracter() );
} Build an instance of the SQLExceptionConverter preferred by this dialect for
converting SQLExceptions into Hibernate's JDBCException hierarchy. The default
Dialect implementation simply returns a converter based on X/Open SQLState codes.
It is strongly recommended that specific Dialect implementations override this
method, since interpretation of a SQL error is much more accurate when based on
the ErrorCode rather than the SQLState. Unfortunately, the ErrorCode is a vendor-
specific approach. |
public char closeQuote() {
return '"';
} The character specific to this dialect used to close a quoted identifier. |
public int convertToFirstRowValue(int zeroBasedFirstResult) {
return zeroBasedFirstResult;
} Hibernate APIs explcitly state that setFirstResult() should be a zero-based offset. Here we allow the
Dialect a chance to convert that value based on what the underlying db or driver will expect.
NOTE: what gets passed into #getLimitString(String,int,int) is the zero-based offset. Dialects which
do not #supportsVariableLimit should take care to perform any needed #convertToFirstRowValue
calls prior to injecting the limit values into the SQL string. |
public CaseFragment createCaseFragment() {
return new ANSICaseFragment();
} |
public JoinFragment createOuterJoinFragment() {
return new ANSIJoinFragment();
} |
public boolean doesReadCommittedCauseWritersToBlockReaders() {
return false;
} For the underlying database, is READ_COMMITTED isolation implemented by
forcing readers to wait for write locks to be released? |
public boolean doesRepeatableReadCauseReadersToBlockWriters() {
return false;
} For the underlying database, is REPEATABLE_READ isolation implemented by
forcing writers to wait for read locks to be released? |
public boolean dropConstraints() {
return true;
} Do we need to drop constraints before dropping tables in this dialect? |
public boolean dropTemporaryTableAfterUse() {
return true;
} Do we need to drop the temporary table after use? |
public boolean forUpdateOfColumns() {
// by default we report no support
return false;
} Is FOR UPDATE OF syntax supported? |
public boolean forceLimitUsage() {
return false;
} Generally, if there is no limit applied to a Hibernate query we do not apply any limits
to the SQL query. This option forces that the limit be written to the SQL query. |
public String generateTemporaryTableName(String baseTableName) {
return "HT_" + baseTableName;
} Generate a temporary table name given the bas table. |
public String getAddColumnString() {
throw new UnsupportedOperationException( "No add column syntax supported by Dialect" );
} The syntax used to add a column to a table (optional). |
public String getAddForeignKeyConstraintString(String constraintName,
String[] foreignKey,
String referencedTable,
String[] primaryKey,
boolean referencesPrimaryKey) {
StringBuffer res = new StringBuffer( 30 );
res.append( " add constraint " )
.append( constraintName )
.append( " foreign key (" )
.append( StringHelper.join( ", ", foreignKey ) )
.append( ") references " )
.append( referencedTable );
if ( !referencesPrimaryKey ) {
res.append( " (" )
.append( StringHelper.join( ", ", primaryKey ) )
.append( ')' );
}
return res.toString();
} The syntax used to add a foreign key constraint to a table. |
public String getAddPrimaryKeyConstraintString(String constraintName) {
return " add constraint " + constraintName + " primary key ";
} The syntax used to add a primary key constraint to a table. |
public String getCascadeConstraintsString() {
return "";
} Completely optional cascading drop clause |
public String getCastTypeName(int code) {
return getTypeName( code, Column.DEFAULT_LENGTH, Column.DEFAULT_PRECISION, Column.DEFAULT_SCALE );
} Get the name of the database type appropriate for casting operations
(via the CAST() SQL function) for the given java.sql.Types typecode. |
public String getColumnComment(String comment) {
return "";
} |
public String getCreateMultisetTableString() {
return getCreateTableString();
} Slight variation on #getCreateTableString . Here, we have the
command used to create a table when there is no primary key and
duplicate rows are expected.
Most databases do not care about the distinction; originally added for
Teradata support which does care. |
protected String getCreateSequenceString(String sequenceName) throws MappingException {
throw new MappingException( "Dialect does not support sequences" );
} Typically dialects which support sequences can create a sequence
with a single command. This is convenience form of
#getCreateSequenceStrings 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 . |
protected String getCreateSequenceString(String sequenceName,
int initialValue,
int incrementSize) throws MappingException {
if ( supportsPooledSequences() ) {
return getCreateSequenceString( sequenceName ) + " start with " + initialValue + " increment by " + incrementSize;
}
throw new MappingException( "Dialect does not support pooled sequences" );
} Overloaded form of #getCreateSequenceString(String) , additionally
taking the initial value and increment size to be applied to the sequence
definition.
The default definition is to suffix #getCreateSequenceString(String)
with the string: " start with {initialValue} increment by {incrementSize}" where
{initialValue} and {incrementSize} are replacement placeholders. Generally
dialects should only need to override this method if different key phrases
are used to apply the allocation information. |
public String[] getCreateSequenceStrings(String sequenceName) throws MappingException {
return new String[] { getCreateSequenceString( sequenceName ) };
} Deprecated! Use - #getCreateSequenceString(String, int, int) instead
The multiline script used to create a sequence. |
public String[] getCreateSequenceStrings(String sequenceName,
int initialValue,
int incrementSize) throws MappingException {
return new String[] { getCreateSequenceString( sequenceName, initialValue, incrementSize ) };
} |
public String getCreateTableString() {
return "create table";
} Command used to create a table. |
public String getCreateTemporaryTablePostfix() {
return "";
} Get any fragments needing to be postfixed to the command for
temporary table creation. |
public String getCreateTemporaryTableString() {
return "create table";
} Command used to create a temporary table. |
public String getCurrentTimestampSQLFunctionName() {
// the standard SQL function name is current_timestamp...
return "current_timestamp";
} The name of the database-specific SQL function for retrieving the
current timestamp. |
public String getCurrentTimestampSelectString() {
throw new UnsupportedOperationException( "Database not known to define a current timestamp function" );
} Retrieve the command used to retrieve the current timestammp from the
database. |
public final Properties getDefaultProperties() {
return properties;
} Retrieve a set of default Hibernate properties for this database. |
public static Dialect getDialect() throws HibernateException {
String dialectName = Environment.getProperties().getProperty( Environment.DIALECT );
return instantiateDialect( dialectName );
} Get an instance of the dialect specified by the current System properties. |
public static Dialect getDialect(Properties props) throws HibernateException {
String dialectName = props.getProperty( Environment.DIALECT );
if ( dialectName == null ) {
return getDialect();
}
return instantiateDialect( dialectName );
} Get an instance of the dialect specified by the given properties or by
the current System properties. |
public String getDropForeignKeyString() {
return " drop constraint ";
} |
protected String getDropSequenceString(String sequenceName) throws MappingException {
throw new MappingException( "Dialect does not support sequences" );
} Typically dialects which support sequences can drop a sequence
with a single command. This is convenience form of
#getDropSequenceStrings 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 . |
public String[] getDropSequenceStrings(String sequenceName) throws MappingException {
return new String[]{getDropSequenceString( sequenceName )};
} The multiline script used to drop a sequence. |
public String getForUpdateNowaitString() {
// by default we report no support for NOWAIT lock semantics
return getForUpdateString();
} Retrieves the FOR UPDATE NOWAIT syntax specific to this dialect. |
public String getForUpdateNowaitString(String aliases) {
return getForUpdateString( aliases );
} Get the FOR UPDATE OF column_list NOWAIT fragment appropriate
for this dialect given the aliases of the columns to be write locked. |
public String getForUpdateString() {
return " for update";
} Get the string to append to SELECT statements to acquire locks
for this dialect. |
public String getForUpdateString(LockMode lockMode) {
if ( lockMode==LockMode.UPGRADE ) {
return getForUpdateString();
}
else if ( lockMode==LockMode.UPGRADE_NOWAIT ) {
return getForUpdateNowaitString();
}
else if ( lockMode==LockMode.FORCE ) {
return getForUpdateNowaitString();
}
else {
return "";
}
} Given a lock mode, determine the appropriate for update fragment to use. |
public String getForUpdateString(String aliases) {
// by default we simply return the getForUpdateString() result since
// the default is to say no support for "FOR UPDATE OF ..."
return getForUpdateString();
} Get the FOR UPDATE OF column_list fragment appropriate for this
dialect given the aliases of the columns to be write locked. |
public final Map getFunctions() {
return sqlFunctions;
} |
public String getHibernateTypeName(int code) throws HibernateException {
String result = hibernateTypeNames.get( code );
if ( result == null ) {
throw new HibernateException( "No Hibernate type mapping for java.sql.Types code: " + code );
}
return result;
} |
public String getHibernateTypeName(int code,
int length,
int precision,
int scale) throws HibernateException {
String result = hibernateTypeNames.get( code, length, precision, scale );
if ( result == null ) {
throw new HibernateException(
"No Hibernate type mapping for java.sql.Types code: " +
code +
", length: " +
length
);
}
return result;
} |
protected String getIdentityColumnString() throws MappingException {
throw new MappingException( "Dialect does not support identity key generation" );
} The syntax used during DDL to define a column as being an IDENTITY. |
public String getIdentityColumnString(int type) throws MappingException {
return getIdentityColumnString();
} The syntax used during DDL to define a column as being an IDENTITY of
a particular type. |
public String getIdentityInsertString() {
return null;
} 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. |
protected String getIdentitySelectString() throws MappingException {
throw new MappingException( "Dialect does not support identity key generation" );
} Get the select command to use to retrieve the last generated IDENTITY
value. |
public String getIdentitySelectString(String table,
String column,
int type) throws MappingException {
return getIdentitySelectString();
} Get the select command to use to retrieve the last generated IDENTITY
value for a particuar table |
public Set getKeywords() {
return sqlKeywords;
} |
protected String getLimitString(String query,
boolean hasOffset) {
throw new UnsupportedOperationException( "paged queries not supported" );
} Apply s limit clause to the query.
Typically dialects utilize variable
limit caluses 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) . |
public String getLimitString(String query,
int offset,
int limit) {
return getLimitString( query, ( offset > 0 || forceLimitUsage() ) );
} Given a limit and an offset, apply the limit clause to the query. |
public LockingStrategy getLockingStrategy(Lockable lockable,
LockMode lockMode) {
return new SelectLockingStrategy( lockable, lockMode );
} Get a strategy instance which knows how to acquire a database-level lock
of the specified mode for this dialect. |
public String getLowercaseFunction() {
return "lower";
} The name of the SQL function that transforms a string to
lowercase |
public int getMaxAliasLength() {
return 10;
} What is the maximum length Hibernate can use for generated aliases? |
public Class getNativeIdentifierGeneratorClass() {
if ( supportsIdentityColumns() ) {
return IdentityGenerator.class;
}
else if ( supportsSequences() ) {
return SequenceGenerator.class;
}
else {
return TableHiLoGenerator.class;
}
} The class (which implements org.hibernate.id.IdentifierGenerator )
which acts as this dialects native generation strategy.
Comes into play whenever the user specifies the native generator. |
public String getNoColumnsInsertString() {
return "values ( )";
} The fragment used to insert a row without specifying any column values.
This is not possible on some databases. |
public String getNullColumnString() {
return "";
} The keyword used to specify a nullable column. |
public String getQuerySequencesString() {
return null;
} Get the select command used retrieve the names of all sequences. |
public ResultSet getResultSet(CallableStatement statement) throws SQLException {
throw new UnsupportedOperationException(
getClass().getName() +
" does not support resultsets via stored procedures"
);
} |
public String getSelectClauseNullString(int sqlType) {
return "null";
} 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. |
public String getSelectGUIDString() {
throw new UnsupportedOperationException( "dialect does not support GUIDs" );
} Get the command used to select a GUID from the underlying database.
Optional operation. |
public String getSelectSequenceNextValString(String sequenceName) throws MappingException {
throw new MappingException( "Dialect does not support sequences" );
} Generate the select expression fragment that will retreive 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. |
public String getSequenceNextValString(String sequenceName) throws MappingException {
throw new MappingException( "Dialect does not support sequences" );
} Generate the appropriate select statement to to retreive the next value
of a sequence.
This should be a "stand alone" select statement. |
public String getTableComment(String comment) {
return "";
} |
public String getTableTypeString() {
// grrr... for differentiation of mysql storage engines
return "";
} |
public String getTypeName(int code) throws HibernateException {
String result = typeNames.get( code );
if ( result == null ) {
throw new HibernateException( "No default type mapping for (java.sql.Types) " + code );
}
return result;
} Get the name of the database type associated with the given
java.sql.Types typecode. |
public String getTypeName(int code,
int length,
int precision,
int scale) throws HibernateException {
String result = typeNames.get( code, length, precision, scale );
if ( result == null ) {
throw new HibernateException(
"No type mapping for java.sql.Types code: " +
code +
", length: " +
length
);
}
return result;
} Get the name of the database type associated with the given
java.sql.Types typecode with the given storage specification
parameters. |
public ViolatedConstraintNameExtracter getViolatedConstraintNameExtracter() {
return EXTRACTER;
} |
public boolean hasAlterTable() {
return true;
} Does this dialect support the ALTER TABLE syntax? |
public boolean hasDataTypeInIdentityColumn() {
return true;
} Whether this dialect have an Identity clause added to the data type or a
completely seperate identity data type |
public boolean hasSelfReferentialForeignKeyBug() {
return false;
} |
public boolean isCurrentTimestampSelectStringCallable() {
throw new UnsupportedOperationException( "Database not known to define a current timestamp function" );
} |
public char openQuote() {
return '"';
} The character specific to this dialect used to begin a quoted identifier. |
public Boolean performTemporaryTableDDLInIsolation() {
return null;
} 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
java.sql.DatabaseMetaData#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: |
public boolean qualifyIndexName() {
return true;
} Do we need to qualify index names with the schema name? |
public final String quote(String column) {
if ( column.charAt( 0 ) == '`' ) {
return openQuote() + column.substring( 1, column.length() - 1 ) + closeQuote();
}
else {
return column;
}
} Apply dialect-specific quoting.
By default, the incoming value is checked to see if its first character
is the back-tick (`). If so, the dialect specific quoting is applied. |
protected void registerColumnType(int code,
String name) {
typeNames.put( code, name );
} Subclasses register a type name for the given type code. $l in
the type name with be replaced by the column length (if appropriate). |
protected void registerColumnType(int code,
int capacity,
String name) {
typeNames.put( code, capacity, name );
} Subclasses register a type name for the given type code and maximum
column length. $l in the type name with be replaced by the
column length (if appropriate). |
protected void registerFunction(String name,
SQLFunction function) {
sqlFunctions.put( name, function );
} |
protected void registerHibernateType(int code,
String name) {
hibernateTypeNames.put( code, name);
} |
protected void registerHibernateType(int code,
int capacity,
String name) {
hibernateTypeNames.put( code, capacity, name);
} |
protected void registerKeyword(String word) {
sqlKeywords.add(word);
} |
public int registerResultSetOutParameter(CallableStatement statement,
int position) throws SQLException {
throw new UnsupportedOperationException(
getClass().getName() +
" does not support resultsets via stored procedures"
);
} Registers an OUT parameter which will be returing a
java.sql.ResultSet . How this is accomplished varies greatly
from DB to DB, hence its inclusion (along with #getResultSet ) here. |
public boolean requiresCastingOfParametersInSelectClause() {
return false;
} Does this dialect require that parameters appearing in the SELECT clause be wrapped in cast()
calls to tell the db parser the expected type. |
public boolean supportsBindAsCallableArgument() {
return true;
} Does this dialect support using a JDBC bind parameter as an argument
to a function or procedure call? |
public boolean supportsCascadeDelete() {
return true;
} |
public boolean supportsCircularCascadeDeleteConstraints() {
return true;
} Does this dialect support definition of cascade delete constraints
which can cause circular chains? |
public boolean supportsColumnCheck() {
return true;
} Does this dialect support column-level check constraints? |
public boolean supportsCommentOn() {
return false;
} |
public boolean supportsCurrentTimestampSelection() {
return false;
} Does this dialect support a way to retrieve the database's current
timestamp value? |
public boolean supportsEmptyInList() {
return true;
} Does this dialect support empty IN lists?
For example, is [where XYZ in ()] a supported construct? |
public boolean supportsExistsInSelect() {
return true;
} Does the dialect support an exists statement in the select clause? |
public boolean supportsExpectedLobUsagePattern() {
return true;
} Expected LOB usage pattern is such that I can perform an insert
via prepared statement with a parameter binding for a LOB value
without crazy casting to JDBC driver implementation-specific classes...
Part of the trickiness here is the fact that this is largely
driver dependent. For example, Oracle (which is notoriously bad with
LOB support in their drivers historically) actually does a pretty good
job with LOB support as of the 10.2.x versions of their drivers... |
public boolean supportsIdentityColumns() {
return false;
} Does this dialect support identity column key generation? |
public boolean supportsIfExistsAfterTableName() {
return false;
} |
public boolean supportsIfExistsBeforeTableName() {
return false;
} |
public boolean supportsInsertSelectIdentity() {
return false;
} Does the dialect support some form of inserting and selecting
the generated IDENTITY value all in the same statement. |
public boolean supportsLimit() {
return false;
} Does this dialect support some form of limiting query results
via a SQL clause? |
public boolean supportsLimitOffset() {
return supportsLimit();
} Does this dialect's LIMIT support (if any) additionally
support specifying an offset? |
public boolean supportsLobValueChangePropogation() {
return true;
} Does the dialect support propogating 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:
java.sql.Blob#setBinaryStream ,
java.sql.Blob#setBytes(long, byte[]) ,
java.sql.Blob#setBytes(long, byte[], int, int) ,
or java.sql.Blob#truncate(long) .
For CLOBs, the internal value might be changed by:
java.sql.Clob#setAsciiStream(long) ,
java.sql.Clob#setCharacterStream(long) ,
java.sql.Clob#setString(long, String) ,
java.sql.Clob#setString(long, String, int, int) ,
or java.sql.Clob#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 . |
public boolean supportsNotNullUnique() {
return true;
} |
public boolean supportsOuterJoinForUpdate() {
return true;
} Does this dialect support FOR UPDATE in conjunction with
outer joined rows? |
public boolean supportsParametersInInsertSelect() {
return true;
} Does this dialect support parameters within the SELECT clause of
INSERT ... SELECT ... statements? |
public boolean supportsPooledSequences() {
return false;
} Does this dialect support "pooled" sequences. Not aware of a better
name for this. Essentially can we specify the initial and increment values? |
public boolean supportsResultSetPositionQueryMethodsOnForwardOnlyCursor() {
return true;
} 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
java.sql.ResultSet#isAfterLast and
java.sql.ResultSet#isBeforeFirst . Certain drivers do not
allow access to these methods for forward only cursors.
NOTE : this is highly driver dependent! |
public boolean supportsRowValueConstructorSyntax() {
// return false here, as most databases do not properly support this construct...
return false;
} Is this dialect known to support what ANSI-SQL terms "row value
constructor" syntax; sometimes called tuple syntax.
Basically, does it support syntax like
"... where (FIRST_NAME, LAST_NAME) = ('Steve', 'Ebersole') ...". |
public boolean supportsRowValueConstructorSyntaxInInList() {
return false;
} If the dialect supports row values ,
does it offer such support in IN lists as well?
For example, "... where (FIRST_NAME, LAST_NAME) IN ( (?, ?), (?, ?) ) ..." |
public boolean supportsSequences() {
return false;
} Does this dialect support sequences? |
public boolean supportsSubqueryOnMutatingTable() {
return true;
} Does this dialect support referencing the table being mutated in
a subquery. The "table being mutated" is the table referenced in
an UPDATE or a DELETE query. And so can that table then be
referenced in a subquery of said UPDATE/DELETE query.
For example, would the following two syntaxes be supported:
- delete from TABLE_A where ID not in ( select ID from TABLE_A )
- update TABLE_A set NON_ID = 'something' where ID in ( select ID from TABLE_A)
|
public boolean supportsSubselectAsInPredicateLHS() {
return true;
} Are subselects supported as the left-hand-side (LHS) of
IN-predicates.
In other words, is syntax like "... IN (1, 2, 3) ..." supported? |
public boolean supportsTableCheck() {
return true;
} Does this dialect support table-level check constraints? |
public boolean supportsTemporaryTables() {
return false;
} Does this dialect support temporary tables? |
public boolean supportsUnboundedLobLocatorMaterialization() {
return true;
} Is it supported to materialize a LOB locator outside the transaction in
which it was created?
Again, part of the trickiness here is the fact that this is largely
driver dependent.
NOTE: all database I have tested which #supportsExpectedLobUsagePattern()
also support the ability to materialize a LOB outside the owning transaction... |
public boolean supportsUnionAll() {
return false;
} Does this dialect support UNION ALL, which is generally a faster
variant of UNION? |
public boolean supportsUnique() {
return true;
} Does this dialect support the UNIQUE column syntax? |
public boolean supportsUniqueConstraintInCreateAlterTable() {
return true;
} Does this dialect support adding Unique constraints via create and alter table ? |
public boolean supportsVariableLimit() {
return supportsLimit();
} Does this dialect support bind variables (i.e., prepared statememnt
parameters) for its limit/offset? |
public String toBooleanValueString(boolean bool) {
return bool ? "1" : "0";
} The SQL literal value to which this database maps boolean values. |
public String toString() {
return getClass().getName();
} |
public String transformSelectString(String select) {
return select;
} |
public boolean useInputStreamToInsertBlob() {
return true;
} |
public boolean useMaxForLimit() {
return false;
} 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? |
org.hibernate.dialect.Dialect