On 4/4/06, Cris Daniluk <cris.danilu..mail.com> wrote:
> I would just use the sniffer to set the HSQLDBAdapter in the correct state,
> rather than create two versions... because a lot of our HSQLDB support is
> weak in both 1.7 and 1.8, and it would be annoying to have to double-apply
> any enhancements we make - particularly in stored procedure land.
The sniffer sets the correct Adaptor to use. This is the same
pattern we use for other adaptors (like Oracle). The only question is
whether it's better to use HSQLDBNoSchemaAdaptor or HSQLDB17Adaptor.
You shouldn't have to double-apply any changes. You make changes in
HSQLDBAdapter and they'll automatically be picked up in the subclass.
The only thing you have to do in the HSQLDBAdapter class is to be
sure that you call getTableName(DbEntity entity) and
getSchemaName(DbEntity entity) rather than manually computing the
table name or schema name directly with
entity.getFullyQualifiedName(), entity.getSchema() and
entity.getName().
> Re the schema creation, that could be a problem. Because there can be table
> overlap between schemas, that could lead to really confusing behavior. Maybe
> we could use the default schema for the map?
Right now, because no schema is mentioned, it uses the default schema
for the database connection. The only way we can insure that there
are no overlaps is use an AUTO_PK_TABLE in the same schema as the
relevent entity. I think that would complicate the AUTO_PK_TABLE
rules, though.
This archive was generated by hypermail 2.0.0 : Tue Apr 04 2006 - 15:40:11 EDT