Re: [Hibernate-devel] Obstacles creating a new dialect.

[Gavin_King/Cirrus%<CI...@ci...>]

>Problem #1: Progress requires you to either always prefix table names
>with a schema, or, alternatively use SET SCHEMA 'xxx' to set a default
>schema for your session.

Actually this issue really *should* have been addressed much earlier. I'm
very happy you're looking at it now. Plenty of applications will need to
access data in two diff schemas. I had sort of assumed it would just _work_
... but at the very least the index generation is broken, as you point out
below. Still, it looks like all these issues are to do with the table
generation tool, and not the main persistence engine.

>The next thing to break was the table name used for unique ids,
>"hibernate_unique_key".  This string is hardcoded into
>RelationalDataStore and HiLoGenerator and needed the schema prefix.  My
>feeling is this table name should be part of the mapping rather than
>hardcoded.  Another idea was to make the table name an attribute of
>Dialect.  RelationDataStore looks reasaonbly easy to modify but I'm not
>so sure about HiLoGenerator.  Any comments?

The hardcoded value is a default. You can specify your own table/column
name for the HiLoGenerator. But, of course, the table generation tool
doesn't know about any others. What we would really want is for Datastore
to have a list of all the HiLoGenerators that were created while reading in
the mapping. I hadn't got up to this yet.

(1) could you please put it in as a feature request
(2) any volunteers?

>The last obstacle with the schema prefix was Collection.createIndex()
>forms index names by added IDX to the table name.  With a schema
>prepended to the table name this resulted in index names which caused
>SQL syntax errors.  My quick fix for this was to get the createIndex
>method to stip off the schema prefix when it created the index name.
>I'm open to ideas for a better solution.

That's not such a bad solution. A better one might be if we have some
schema="" attribute everywhere table="" appears and then have
getQualifiedTableName() as well as getTableName() on things.... its more
work though.....your suggestion is probably cool for now.

>Problem #2: testFind is throwing an exception during
>RelationalDatabaseSession.flush().   Haven't been able to figure this
>one out yet so will willingly accept any advice as to what may be the
>cause.  Below is the output trace when debug is set to 4.

Just a guess ..... It kind of *looks* like this bug has to do with reusing
prepared statements for this JDBC driver. Hibernate keeps any prepared
statements it uses in a cache on RelationalDatabaseSession. You could
disable this cache by defacing
RelationalDatabaseSession.getPreparedStatement() and see if the error still
occurs. If it doesn't, perhaps some System property to disable cacheing is
in order....