Community
Participate
Working Groups
TO create a JDBC connection profile instance, 2 DTP-specific properties are needed: 1) database vendor (IJDBCConnectionProfileConstants.DATABASE_VENDOR_PROP_ID) 2) database version (IJDBCConnectionProfileConstants.DATABASE_VERSION_PROP_ID) These 2 properties may be dynamically detected by mapping to the database meta data obtained from a live JDBC connection. The existing o.e.d.c.sqm.core.IDatabaseRecognizer interface supports defining such mapping in a Java implementation class. Its #recognize( java.sql.Connection ) method returns a DatabaseDefinition instance. The mapping however may be specific to individual JDBC driver, and adopters would likely have to add their own product-specific mapping. For ease of defining the mapping between a JDBC database product name and version values to those of a DTP enablement driver template, this proposes to support defining the mapping through an extension point. The DTP distribution should also include more of such mappings out of the box in the enablement components. (A separate BZ should probably be created for this.) In addition, related API to access the mapping utility, e.g. RDBCorePlugin.getDefault().getDatabaseDefinitionRegistry(), should be made public for client access.
I will start on this with a proposal of the extension point schema definition.
Created attachment 127776 [details] Proposed enhancement to databaseRecognition extension point xsd Attached is proposed enhancement to the schema definition of the org.eclipse.datatools.connectivity.sqm.core.databaseRecognition extension point. A new generic IDatabaseRecognizer impl class would use these dbdefinition product and version mapping elements to determine a DatabaseDefinition instance. This new db recognizer will be appended to the list of loaded IDatabaseRecognizer, and will get used only if the other recognizers are not able to find a matching DatabaseDefinition instance. An extension may of course also specify this new generic IDatabaseRecognizer impl class in the recognizer element.
Larry, Brian, Can you guys take a look at the attached patch for the proposed enhancement to the org.eclipse.datatools.connectivity.sqm.core.databaseRecognition exsd? I'm trying to get at least the exsd changes in M6, if it looks ok. Thanks.
Looks fine to me. But can you explain a common use case here to better illustrate how it will be used?
Since DTP provides very little built-in out-of-box database recognizers, an adopter can add their own databaseRecognition extension for the databases that they use. Instead of implementing an IDatabaseRecognizer that covers the specific product name and version metadata returned by their JDBC drivers, a DBA can simply define the mapping in plugin.xml between a JDBC database product name and version values to those of a DTP enablement driver template.
So are we planning on including a default dbRecognizer instance?
This solution seems incomplete. The UI has version specific driver definitions, for example, Oracle 9. Then at runtime, you want the capability to rewrite the version so that it is Oracle 10. Seems to me that it will confuse the user. The best approach is to implement a complete DBRecognizer and then remove the versioned driver templates such as what was done for DB2 LUW.
But isn't the goal in this case to try and not write a DB recognizer for every single database, since we don't necessarily know the JDBC drivers being used in all cases?
I guess I don't understand the point of the change. If the adopter has to add mappings to support a new driver, don't they need to implement a new driver UI to support that driver anyway? I don't see the value in just adding mappings.
Yeah, that's sort of why I'm wondering about an actual use case with specifics. (In reply to comment #5) > Since DTP provides very little built-in out-of-box database recognizers, an > adopter can add their own databaseRecognition extension for the databases that > they use. > Instead of implementing an IDatabaseRecognizer that covers the specific product > name and version metadata returned by their JDBC drivers, a DBA can simply > define the mapping in plugin.xml between a JDBC database product name and > version values to those of a DTP enablement driver template. Linda, you say a DBA can simply define the mapping in plugin.xml... Where is this mapping used? What mechanism is there going to be and where would that mechanism be used I guess.
>> So are we planning on including a default dbRecognizer instance? Yes, that is the "new generic IDatabaseRecognizer impl class" described in comment #2. This whole thing is not for introducing a new db version, but to use an existing dbdefinition (product and version). The usage scenario is an application needs to automatically create a connection profile instance (to use with the DTP SQM framework), based on a JDBC connection. So we need to systematically figure out which existing dbdefinition to use in the profile. Thus the db recogition mapping to specify which existing db product and version to apply based on a JDBC driver's db metadata. The parent bug #253630 has more description on this usage scenario. The RDBCorePlugin.getDefault().getDatabaseDefinitionRegistry() can then be called by the client application to get the DatabaseDefinition instance, based on a JDBC connection.
Thanks for the explanation. It makes sense to me. Patch looks good.
Yup. Works for me also. Go for it.
Committed exsd changes with tag v200903100225.
Created attachment 128136 [details] Implementation Patch Implementation to support the enhanced extension point exsd. Larry, Brian, Please review. Thanks.
The patch looks good.
Thanks for the review. Delivered implementation with tag v200903120450.
