On 4/4/06, Cris Daniluk <[EMAIL PROTECTED]> 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.
