Hi Caolán, > What I'm finding kind of hard though to find out though is if jdbc > drivers should only be assumed to support setting primary keys if > supportsCoreSQLGrammar is enabled and OOo is totally correct in what it > does, and its a matter for postgres-jdbc to support it to get this to > work. > > Or if OOo is looking for more than it needs, e.g. some variation on > supportsMinimumSQLGrammar || supportsCoreSQLGrammar || > supportsANSI92EntryLevelSQL is sufficient to enable setting primary keys > or even if jdbc drivers should always be assumed to support setting > primary keys ?
Requiring core SQL grammar for PK support is more of a heuristics (one I didn't even know 'til know we use :) - that code must be really old). Unfortunately, the current available MSDN ODBC SDK doesn't really define core SQL grammar (but only minimum SQL grammar), so I am not sure how correct this heuristics is. Either way, nowadays we would implement this in another way: A driver should be able to explicitly tell which features it (respectively its database) supports. Since there doesn't exist an API for this, we used to have some hard-coded meta-information like this in the code (e.g. which DBs support primary keys, which formerly was determined by a "supportsIntegrityEnhancementFacilities"-heuristics). With CWS dbaperf2, we moved forward to a configuration-based approach. That is, every driver is accompanied by configuration data describing its capabilities. Here, we could introduce a "PK-support" feature in the configuration data. For generic drivers like the JDBC-SDBC-, ODBC-SDBC-, and ADO-SDBC bridge, I tend to say they should always claim to support PKs, and leave it to the system driver to reject PKs if they're actually not supported. Ciao Frank -- - Frank Schönheit, Software Engineer [email protected] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
