HIBERNATE DIRECTORIES AND 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é.

The directory (or directories) where hibernate.properties and/or hibernate.cfg.xml are kept.

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:

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:

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

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.

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.

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.

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

getLimitString

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

a "static" delegate based on the JDBC 4 defined SQLException hierarchy;

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.

supportsResultSetPositionQueryMethodsOnForwardOnlyCursor

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.