Cache71Dialect (Hibernate JavaDocs)
Date: 2012-04-05

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

## org.hibernate.dialect
Class Cache71Dialect

    java.lang.Object
      org.hibernate.dialect.Dialect
          org.hibernate.dialect.Cache71Dialect

All Implemented Interfaces:
  ConversionContext

    public class Cache71Dialect

extends Dialect

Caché 2007.1 dialect. This class is required in order to use Hibernate with Intersystems Caché SQL.
Compatible with Caché 2007.1.
Caché and Hibernate

# Caché and Hibernate

## PREREQUISITES

These setup instructions assume that both Caché and Hibernate are installed and operational.

## HIBERNATE DIRECTORIES AND FILES

JBoss distributes the InterSystems Cache' dialect for Hibernate 3.2.1 For earlier versions of Hibernate please contact InterSystems Worldwide Response Center (WRC) for the appropriate source files.

## CACHÉ DOCUMENTATION

Documentation for Caché is available online when Caché is running. It can also be obtained from the InterSystems website. The book, "Object-oriented Application Development Using the Caché Post-relational Database: is also available from Springer-Verlag.

## HIBERNATE DOCUMENTATION

Hibernate comes with extensive electronic documentation. In addition, several books on Hibernate are available from Manning Publications Co. Three available titles are "Hibernate Quickly", "Hibernate in Action", and "Java Persistence with Hibernate".

## TO SET UP HIBERNATE FOR USE WITH CACHÉ

The following steps assume that the directory where Caché was installed is C:\CacheSys. This is the default installation directory for Caché. The default installation directory for Hibernate is assumed to be C:\Hibernate.

If either product is installed in a different location, the pathnames that follow should be modified appropriately.

Caché version 2007.1 and above is recommended for use with Hibernate. The next step depends on the location of your CacheDB.jar depending on your version of Caché.

1. Copy C:\CacheSys\dev\java\lib\JDK15\CacheDB.jar to C:\Hibernate\lib\CacheDB.jar.

2. Insert the following files into your Java classpath:

   - All jar files in the directory C:\Hibernate\lib
   - The directory (or directories) where hibernate.properties and/or hibernate.cfg.xml are kept.

3. In the file, hibernate.properties (or hibernate.cfg.xml), specify the Caché dialect and the Caché version URL settings.

For example, in Hibernate 3.2, typical entries in hibernate.properties would have the following "name=value" pairs:

Property Name | Property Value
--- | ---
hibernate.dialect | org.hibernate.dialect.Cache71Dialect
hibernate.connection.driver_class | com.intersys.jdbc.CacheDriver
hibernate.connection.username | (see note 1)
hibernate.connection.password | (see note 1)
hibernate.connection.url | jdbc:Cache://127.0.0.1:1972/USER

Note 1
  Please contact your administrator for the userid and password you should use when attempting access via JDBC. By default, these are chosen to be "_SYSTEM" and "SYS" respectively as noted in the SQL standard.

## CACHÉ VERSION URL

This is the standard URL for the JDBC driver. For a JDBC driver on the machine hosting Caché, use the IP "loopback" address, 127.0.0.1. For 1972, the default port, specify the super server port of your Caché instance. For USER, substitute the NAMESPACE which contains your Caché database data.

## CACHÉ DIALECTS

Choices for Dialect are:

1. org.hibernate.dialect.Cache71Dialect (requires Caché 2007.1 or above)

## SUPPORT FOR IDENTITY COLUMNS

Caché 2007.1 or later supports identity columns. For Hibernate to use identity columns, specify "native" as the generator.

## SEQUENCE DIALECTS SUPPORT SEQUENCES

To use Hibernate sequence support with Caché in a namespace, you must FIRST load the following file into that namespace:

         etc\CacheSequences.xml

For example, at the COS terminal prompt in the namespace, run the following command:

d LoadFile^%apiOBJ("c:\hibernate\etc\CacheSequences.xml","ck")

In your Hibernate mapping you can specify sequence use.

For example, the following shows the use of a sequence generator in a Hibernate mapping:

         <id name="id" column="uid" type="long" unsaved-value="null">
             <generator class="sequence"/>
         </id>

Some versions of Hibernate under some circumstances call getSelectSequenceNextValString() in the dialect. If this happens you will receive the error message: new MappingException( "Dialect does not support sequences" ).

## HIBERNATE FILES ASSOCIATED WITH CACHÉ DIALECT

The following files are associated with Caché dialect:

1. src\org\hibernate\dialect\Cache71Dialect.java
2. src\org\hibernate\dialect\function\ConditionalParenthesisFunction.java
3. src\org\hibernate\dialect\function\ConvertFunction.java
4. src\org\hibernate\exception\CacheSQLStateConverter.java
5. src\org\hibernate\sql\CacheJoinFragment.java

Cache71Dialect ships with Hibernate 3.2. All other dialects are distributed by InterSystems and subclass Cache71Dialect.

Field Summary
`static ViolatedConstraintNameExtracter` | `EXTRACTER`

Fields inherited from class org.hibernate.dialect.Dialect
`CLOSED_QUOTE, DEFAULT_BATCH_SIZE, LEGACY_LOB_MERGE_STRATEGY, NEW_LOCATOR_LOB_MERGE_STRATEGY, NO_BATCH, QUOTE, STREAM_XFER_LOB_MERGE_STRATEGY`

Constructor Summary
`Cache71Dialect()` Creates new `Cache71Dialect` instance.

Method Summary
`boolean` | `areStringComparisonsCaseInsensitive()` Are string comparisons implicitly case insensitive.
`boolean` | `bindLimitParametersFirst()` Does the `LIMIT` clause come at the start of the `SELECT` statement, rather than at the end?
`SQLExceptionConversionDelegate` | `buildSQLExceptionConversionDelegate()` Build an instance of a `SQLExceptionConversionDelegate` for interpreting dialect-specific error or SQLState codes.
`protected void` | `commonRegistration()`
`JoinFragment` | `createOuterJoinFragment()` Create a `JoinFragment` strategy responsible for handling this dialect's variations in how joins are handled.
`boolean` | `dropConstraints()` Do we need to drop constraints before dropping tables in this dialect?
`boolean` | `dropTemporaryTableAfterUse()` Do we need to drop the temporary table after use?
`String` | `generateTemporaryTableName(String baseTableName)` Generate a temporary table name given the base table.
`String` | `getAddColumnString()` The syntax used to add a column to a table (optional).
`String` | `getAddForeignKeyConstraintString(String constraintName, String[] foreignKey, String referencedTable, String[] primaryKey, boolean referencesPrimaryKey)` The syntax used to add a foreign key constraint to a table.
`String` | `getCascadeConstraintsString()` Completely optional cascading drop clause
`String` | `getCreateTemporaryTablePostfix()` Get any fragments needing to be postfixed to the command for temporary table creation.
`String` | `getCreateTemporaryTableString()` Command used to create a temporary table.
`String` | `getIdentityColumnString()` The syntax used during DDL to define a column as being an IDENTITY.
`String` | `getIdentitySelectString()` Get the select command to use to retrieve the last generated IDENTITY value.
`String` | `getLimitString(String sql, boolean hasOffset)` Apply s limit clause to the query.
`LockingStrategy` | `getLockingStrategy(Lockable lockable, LockMode lockMode)` Get a strategy instance which knows how to acquire a database-level lock of the specified mode for this dialect.
`String` | `getLowercaseFunction()` The name of the SQL function that transforms a string to lowercase
`Class` | `getNativeIdentifierGeneratorClass()` The class (which implements `IdentifierGenerator`) which acts as this dialects native generation strategy.
`String` | `getNoColumnsInsertString()` The fragment used to insert a row without specifying any column values.
`String` | `getNullColumnString()` The keyword used to specify a nullable column.
`ResultSet` | `getResultSet(CallableStatement ps)` Given a callable statement previously processed by `Dialect.registerResultSetOutParameter(java.sql.CallableStatement, int)`, extract the `ResultSet` from the OUT parameter.
`ViolatedConstraintNameExtracter` | `getViolatedConstraintNameExtracter()`
`boolean` | `hasAlterTable()` Does this dialect support the `ALTER TABLE` syntax?
`boolean` | `hasDataTypeInIdentityColumn()` Whether this dialect have an Identity clause added to the data type or a completely separate identity data type
`boolean` | `hasSelfReferentialForeignKeyBug()`
`Boolean` | `performTemporaryTableDDLInIsolation()` 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.
`boolean` | `qualifyIndexName()` Do we need to qualify index names with the schema name?
`protected void` | `register71Functions()`
`int` | `registerResultSetOutParameter(CallableStatement statement, int col)` Registers an OUT parameter which will be returning a `ResultSet`.
`boolean` | `supportsCascadeDelete()`
`boolean` | `supportsCheck()`
`boolean` | `supportsEmptyInList()` Does this dialect support empty IN lists? For example, is [where XYZ in ()] a supported construct?
`boolean` | `supportsForUpdate()`
`boolean` | `supportsForUpdateNowait()`
`boolean` | `supportsForUpdateOf()`
`boolean` | `supportsIdentityColumns()` Does this dialect support identity column key generation?
`boolean` | `supportsLimit()` Does this dialect support some form of limiting query results via a SQL clause?
`boolean` | `supportsLimitOffset()` Does this dialect's LIMIT support (if any) additionally support specifying an offset?
`boolean` | `supportsOuterJoinForUpdate()` Does this dialect support `FOR UPDATE` in conjunction with outer joined rows?
`boolean` | `supportsResultSetPositionQueryMethodsOnForwardOnlyCursor()` Does this dialect support asking the result set its positioning information on forward only cursors.
`boolean` | `supportsSequences()` Does this dialect support sequences?
`boolean` | `supportsTemporaryTables()` Does this dialect support temporary tables?
`boolean` | `supportsUnique()` Does this dialect support the `UNIQUE` column syntax?
`boolean` | `supportsVariableLimit()` Does this dialect support bind variables (i.e., prepared statement parameters) for its limit/offset?
`boolean` | `useMaxForLimit()` Does the `LIMIT` clause take a "maximum" row number instead of a total number of returned rows? This is easiest understood via an example.

Methods inherited from class org.hibernate.dialect.Dialect
`appendIdentitySelectToInsert, appendLockHint, applyLocksToSql, bindLimitParametersInReverseOrder, buildSQLExceptionConverter, closeQuote, convertToFirstRowValue, createCaseFragment, doesReadCommittedCauseWritersToBlockReaders, doesRepeatableReadCauseReadersToBlockWriters, forceLimitUsage, forUpdateOfColumns, getAddPrimaryKeyConstraintString, getAddUniqueConstraintString, getCaseInsensitiveLike, getCastTypeName, getColumnAliasExtractor, getColumnComment, getCreateMultisetTableString, getCreateSequenceString, getCreateSequenceString, getCreateSequenceStrings, getCreateSequenceStrings, getCreateTableString, getCrossJoinSeparator, getCurrentTimestampSelectString, getCurrentTimestampSQLFunctionName, getDefaultProperties, getDialect, getDialect, getDropForeignKeyString, getDropSequenceString, getDropSequenceStrings, getDropTemporaryTableString, getForUpdateNowaitString, getForUpdateNowaitString, getForUpdateString, getForUpdateString, getForUpdateString, getForUpdateString, getForUpdateString, getFunctions, getHibernateTypeName, getHibernateTypeName, getIdentityColumnString, getIdentityInsertString, getIdentitySelectString, getKeywords, getLimitString, getLobMergeStrategy, getMaxAliasLength, getQuerySequencesString, getReadLockString, getSelectClauseNullString, getSelectGUIDString, getSelectSequenceNextValString, getSequenceNextValString, getSqlTypeDescriptorOverride, getTableComment, getTableTypeString, getTypeName, getTypeName, getWriteLockString, isCurrentTimestampSelectStringCallable, isLockTimeoutParameterized, openQuote, quote, registerColumnType, registerColumnType, registerFunction, registerHibernateType, registerHibernateType, registerKeyword, remapSqlTypeDescriptor, replaceResultVariableInOrderByClauseWithPosition, requiresCastingOfParametersInSelectClause, supportsBindAsCallableArgument, supportsCaseInsensitiveLike, supportsCircularCascadeDeleteConstraints, supportsColumnCheck, supportsCommentOn, supportsCurrentTimestampSelection, supportsExistsInSelect, supportsExpectedLobUsagePattern, supportsIfExistsAfterTableName, supportsIfExistsBeforeTableName, supportsInsertSelectIdentity, supportsLobValueChangePropogation, supportsLockTimeouts, supportsNotNullUnique, supportsParametersInInsertSelect, supportsPooledSequences, supportsRowValueConstructorSyntax, supportsRowValueConstructorSyntaxInInList, supportsSubqueryOnMutatingTable, supportsSubselectAsInPredicateLHS, supportsTableCheck, supportsTupleCounts, supportsTupleDistinctCounts, supportsUnboundedLobLocatorMaterialization, supportsUnionAll, supportsUniqueConstraintInCreateAlterTable, toBooleanValueString, toString, transformSelectString, useInputStreamToInsertBlob`

Methods inherited from class java.lang.Object
`clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait`

Field Detail

### EXTRACTER

    public static final ViolatedConstraintNameExtracter EXTRACTER

Constructor Detail

### Cache71Dialect

    public Cache71Dialect()

  Creates new `Cache71Dialect` instance. Sets up the JDBC / Caché type mappings.

Method Detail

### commonRegistration

    protected final void commonRegistration()

### register71Functions

    protected final void register71Functions()

### hasAlterTable

    public boolean hasAlterTable()

  Description copied from class: `Dialect`
  Does this dialect support the `ALTER TABLE` syntax?

  Overrides:
    `hasAlterTable` in class `Dialect`
  Returns:
    True if we support altering of tables; false otherwise.

### qualifyIndexName

    public boolean qualifyIndexName()

  Description copied from class: `Dialect`
  Do we need to qualify index names with the schema name?

  Overrides:
    `qualifyIndexName` in class `Dialect`
  Returns:
    boolean

### supportsUnique

    public boolean supportsUnique()

  Description copied from class: `Dialect`
  Does this dialect support the `UNIQUE` column syntax?

  Overrides:
    `supportsUnique` in class `Dialect`
  Returns:
    boolean

### getAddForeignKeyConstraintString

    public String getAddForeignKeyConstraintString(String constraintName,
                                                   String[] foreignKey,
                                                   String referencedTable,
                                                   String[] primaryKey,
                                                   boolean referencesPrimaryKey)

  The syntax used to add a foreign key constraint to a table.

  Overrides:
    `getAddForeignKeyConstraintString` in class `Dialect`
  Parameters:
    `constraintName` - The FK constraint name.
    `foreignKey` - The names of the columns comprising the FK
    `referencedTable` - The table referenced by the FK
    `primaryKey` - The explicit columns in the referencedTable referenced by this FK.
    `referencesPrimaryKey` - if false, constraint should be explicit about which column names the constraint refers to
  Returns:
    String

### supportsCheck

    public boolean supportsCheck()

### getAddColumnString

    public String getAddColumnString()

  Description copied from class: `Dialect`
  The syntax used to add a column to a table (optional).

  Overrides:
    `getAddColumnString` in class `Dialect`
  Returns:
    The "add column" fragment.

### getCascadeConstraintsString

    public String getCascadeConstraintsString()

  Description copied from class: `Dialect`
  Completely optional cascading drop clause

  Overrides:
    `getCascadeConstraintsString` in class `Dialect`
  Returns:
    String

### dropConstraints

    public boolean dropConstraints()

  Description copied from class: `Dialect`
  Do we need to drop constraints before dropping tables in this dialect?

  Overrides:
    `dropConstraints` in class `Dialect`
  Returns:
    True if constraints must be dropped prior to dropping the table; false otherwise.

### supportsCascadeDelete

    public boolean supportsCascadeDelete()

  Overrides:
    `supportsCascadeDelete` in class `Dialect`

### hasSelfReferentialForeignKeyBug

    public boolean hasSelfReferentialForeignKeyBug()

  Overrides:
    `hasSelfReferentialForeignKeyBug` in class `Dialect`

### supportsTemporaryTables

    public boolean supportsTemporaryTables()

  Description copied from class: `Dialect`
  Does this dialect support temporary tables?

  Overrides:
    `supportsTemporaryTables` in class `Dialect`
  Returns:
    True if temp tables are supported; false otherwise.

### generateTemporaryTableName

    public String generateTemporaryTableName(String baseTableName)

  Description copied from class: `Dialect`
  Generate a temporary table name given the base table.

  Overrides:
    `generateTemporaryTableName` in class `Dialect`
  Parameters:
    `baseTableName` - The table name from which to base the temp table name.
  Returns:
    The generated temp table name.

### getCreateTemporaryTableString

    public String getCreateTemporaryTableString()

  Description copied from class: `Dialect`
  Command used to create a temporary table.

  Overrides:
    `getCreateTemporaryTableString` in class `Dialect`
  Returns:
    The command used to create a temporary table.

### performTemporaryTableDDLInIsolation

    public Boolean performTemporaryTableDDLInIsolation()

  Description copied from class: `Dialect`
  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 `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:
  - `Boolean.TRUE` - Unequivocally, perform the temporary table DDL in isolation.
  - `Boolean.FALSE` - Unequivocally, do not perform the temporary table DDL in isolation.
  - null - defer to the JDBC driver response in regards to `DatabaseMetaData.dataDefinitionCausesTransactionCommit()`

  Overrides:
    `performTemporaryTableDDLInIsolation` in class `Dialect`
  Returns:
    see the result matrix above.

### getCreateTemporaryTablePostfix

    public String getCreateTemporaryTablePostfix()

  Description copied from class: `Dialect`
  Get any fragments needing to be postfixed to the command for temporary table creation.

  Overrides:
    `getCreateTemporaryTablePostfix` in class `Dialect`
  Returns:
    Any required postfix.

### dropTemporaryTableAfterUse

    public boolean dropTemporaryTableAfterUse()

  Description copied from class: `Dialect`
  Do we need to drop the temporary table after use?

  Overrides:
    `dropTemporaryTableAfterUse` in class `Dialect`
  Returns:
    True if the table should be dropped.

### supportsIdentityColumns

    public boolean supportsIdentityColumns()

  Description copied from class: `Dialect`
  Does this dialect support identity column key generation?

  Overrides:
    `supportsIdentityColumns` in class `Dialect`
  Returns:
    True if IDENTITY columns are supported; false otherwise.

### getNativeIdentifierGeneratorClass

    public Class getNativeIdentifierGeneratorClass()

  Description copied from class: `Dialect`
  The class (which implements `IdentifierGenerator`) which acts as this dialects native generation strategy.

  Comes into play whenever the user specifies the native generator.

  Overrides:
    `getNativeIdentifierGeneratorClass` in class `Dialect`
  Returns:
    The native generator class.

### hasDataTypeInIdentityColumn

    public boolean hasDataTypeInIdentityColumn()

  Description copied from class: `Dialect`
  Whether this dialect have an Identity clause added to the data type or a completely separate identity data type

  Overrides:
    `hasDataTypeInIdentityColumn` in class `Dialect`
  Returns:
    boolean

### getIdentityColumnString

    public String getIdentityColumnString()
                                   throws MappingException

  Description copied from class: `Dialect`
  The syntax used during DDL to define a column as being an IDENTITY.

  Overrides:
    `getIdentityColumnString` in class `Dialect`
  Returns:
    The appropriate DDL fragment.
  Throws:
    `MappingException` - If IDENTITY generation is not supported.

### getIdentitySelectString

    public String getIdentitySelectString()

  Description copied from class: `Dialect`
  Get the select command to use to retrieve the last generated IDENTITY value.

  Overrides:
    `getIdentitySelectString` in class `Dialect`
  Returns:
    The appropriate select command

### supportsSequences

    public boolean supportsSequences()

  Description copied from class: `Dialect`
  Does this dialect support sequences?

  Overrides:
    `supportsSequences` in class `Dialect`
  Returns:
    True if sequences supported; false otherwise.

### supportsForUpdate

    public boolean supportsForUpdate()

### supportsForUpdateOf

    public boolean supportsForUpdateOf()

### supportsForUpdateNowait

    public boolean supportsForUpdateNowait()

### supportsOuterJoinForUpdate

    public boolean supportsOuterJoinForUpdate()

  Description copied from class: `Dialect`
  Does this dialect support `FOR UPDATE` in conjunction with outer joined rows?

  Overrides:
    `supportsOuterJoinForUpdate` in class `Dialect`
  Returns:
    True if outer joined rows can be locked via `FOR UPDATE`.

### getLockingStrategy

    public LockingStrategy getLockingStrategy(Lockable lockable,
                                              LockMode lockMode)

  Description copied from class: `Dialect`
  Get a strategy instance which knows how to acquire a database-level lock of the specified mode for this dialect.

  Overrides:
    `getLockingStrategy` in class `Dialect`
  Parameters:
    `lockable` - The persister for the entity to be locked.
    `lockMode` - The type of lock to be acquired.
  Returns:
    The appropriate locking strategy.

### supportsLimit

    public boolean supportsLimit()

  Description copied from class: `Dialect`
  Does this dialect support some form of limiting query results via a SQL clause?

  Overrides:
    `supportsLimit` in class `Dialect`
  Returns:
    True if this dialect supports some form of LIMIT.

### supportsLimitOffset

    public boolean supportsLimitOffset()

  Description copied from class: `Dialect`
  Does this dialect's LIMIT support (if any) additionally support specifying an offset?

  Overrides:
    `supportsLimitOffset` in class `Dialect`
  Returns:
    True if the dialect supports an offset within the limit support.

### supportsVariableLimit

    public boolean supportsVariableLimit()

  Description copied from class: `Dialect`
  Does this dialect support bind variables (i.e., prepared statement parameters) for its limit/offset?

  Overrides:
    `supportsVariableLimit` in class `Dialect`
  Returns:
    True if bind variables can be used; false otherwise.

### bindLimitParametersFirst

    public boolean bindLimitParametersFirst()

  Description copied from class: `Dialect`
  Does the `LIMIT` clause come at the start of the `SELECT` statement, rather than at the end?

  Overrides:
    `bindLimitParametersFirst` in class `Dialect`
  Returns:
    true if limit parameters should come before other parameters

### useMaxForLimit

    public boolean useMaxForLimit()

  Description copied from class: `Dialect`
  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?

  Overrides:
    `useMaxForLimit` in class `Dialect`
  Returns:
    True if limit is relative from offset; false otherwise.

### getLimitString

    public String getLimitString(String sql,
                                 boolean hasOffset)

  Description copied from class: `Dialect`
  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 `Dialect.getLimitString(String, int, int)`.

  Overrides:
    `getLimitString` in class `Dialect`
  Parameters:
    `sql` - The query to which to apply the limit.
    `hasOffset` - Is the query requesting an offset?
  Returns:
    the modified SQL

### registerResultSetOutParameter

    public int registerResultSetOutParameter(CallableStatement statement,
                                             int col)
                                      throws SQLException

  Description copied from class: `Dialect`
  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 `Dialect.getResultSet(java.sql.CallableStatement)`) here.

  Overrides:
    `registerResultSetOutParameter` in class `Dialect`
  Parameters:
    `statement` - The callable statement.
    `col` - The bind position at which to register the OUT param.
  Returns:
    The number of (contiguous) bind positions used.
  Throws:
    `SQLException` - Indicates problems registering the OUT param.

### getResultSet

    public ResultSet getResultSet(CallableStatement ps)
                           throws SQLException

  Description copied from class: `Dialect`
  Given a callable statement previously processed by `Dialect.registerResultSetOutParameter(java.sql.CallableStatement, int)`, extract the `ResultSet` from the OUT parameter.

  Overrides:
    `getResultSet` in class `Dialect`
  Parameters:
    `ps` - The callable statement.
  Returns:
    The extracted result set.
  Throws:
    `SQLException` - Indicates problems extracting the result set.

### getLowercaseFunction

    public String getLowercaseFunction()

  Description copied from class: `Dialect`
  The name of the SQL function that transforms a string to lowercase

  Overrides:
    `getLowercaseFunction` in class `Dialect`
  Returns:
    The dialect-specific lowercase function.

### getNullColumnString

    public String getNullColumnString()

  Description copied from class: `Dialect`
  The keyword used to specify a nullable column.

  Overrides:
    `getNullColumnString` in class `Dialect`
  Returns:
    String

### createOuterJoinFragment

    public JoinFragment createOuterJoinFragment()

  Description copied from class: `Dialect`
  Create a `JoinFragment` strategy responsible for handling this dialect's variations in how joins are handled.

  Overrides:
    `createOuterJoinFragment` in class `Dialect`
  Returns:
    This dialect's `JoinFragment` strategy.

### getNoColumnsInsertString

    public String getNoColumnsInsertString()

  Description copied from class: `Dialect`
  The fragment used to insert a row without specifying any column values. This is not possible on some databases.

  Overrides:
    `getNoColumnsInsertString` in class `Dialect`
  Returns:
    The appropriate empty values clause.

### buildSQLExceptionConversionDelegate

    public SQLExceptionConversionDelegate buildSQLExceptionConversionDelegate()

  Description copied from class: `Dialect`
  Build an instance of a `SQLExceptionConversionDelegate` for interpreting dialect-specific error or SQLState codes.

  When `Dialect.buildSQLExceptionConverter()` returns null, the default `SQLExceptionConverter` is used to interpret SQLState and error codes. If this method is overridden to return a non-null value, the default `SQLExceptionConverter` will use the returned `SQLExceptionConversionDelegate` in addition to the following standard delegates:
  1. a "static" delegate based on the JDBC 4 defined SQLException hierarchy;
  2. a delegate that interprets SQLState codes for either X/Open or SQL-2003 codes, depending on java.sql.DatabaseMetaData#getSQLStateType

  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 a vendor-specific ErrorCode rather than the SQLState.

  Specific Dialects may override to return whatever is most appropriate for that vendor.

  Overrides:
    `buildSQLExceptionConversionDelegate` in class `Dialect`

### getViolatedConstraintNameExtracter

    public ViolatedConstraintNameExtracter getViolatedConstraintNameExtracter()

  Specified by:
    `getViolatedConstraintNameExtracter` in interface `ConversionContext`
  Overrides:
    `getViolatedConstraintNameExtracter` in class `Dialect`

### supportsEmptyInList

    public boolean supportsEmptyInList()

  Description copied from class: `Dialect`
  Does this dialect support empty IN lists?

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

  Overrides:
    `supportsEmptyInList` in class `Dialect`
  Returns:
    True if empty in lists are supported; false otherwise.

### areStringComparisonsCaseInsensitive

    public boolean areStringComparisonsCaseInsensitive()

  Description copied from class: `Dialect`
  Are string comparisons implicitly case insensitive.

  In other words, does [where 'XYZ' = 'xyz'] resolve to true?

  Overrides:
    `areStringComparisonsCaseInsensitive` in class `Dialect`
  Returns:
    True if comparisons are case insensitive.

### supportsResultSetPositionQueryMethodsOnForwardOnlyCursor

    public boolean supportsResultSetPositionQueryMethodsOnForwardOnlyCursor()

  Description copied from class: `Dialect`
  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 `ResultSet.isAfterLast()` and `ResultSet.isBeforeFirst()`. Certain drivers do not allow access to these methods for forward only cursors.

  NOTE : this is highly driver dependent!

  Overrides:
    `supportsResultSetPositionQueryMethodsOnForwardOnlyCursor` in class `Dialect`
  Returns:
    True if methods like `ResultSet.isAfterLast()` and `ResultSet.isBeforeFirst()` are supported for forward only cursors; false otherwise.

Overview | Package | Class | Use | Tree | Deprecated | Index | Help
PREV CLASS NEXT CLASS | FRAMES NO FRAMES
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD

Copyright © 2001-2012 Red Hat, Inc. All Rights Reserved.