Amita, Yes, I agree with this approach to solving the problem. Since Derby is a first-class DAS citizen, I confirm that it makes sense for it to have special code to ensure it works "out-of-the-box" with no special Config attribute. Thanks for persevering with this issue. Also, thanks in advance for your patch.
Regards, - Ron --- Amita Vadhavkar <[EMAIL PROTECTED]> wrote: > True, with the approach, DAS can use Metadata API > and treat Derby specially > (as > Derby Embedded Driver API returns FALSE, set it to > TRUE) > > 1) If provided in Config - it will be used, no > Metadata API check > 2) If not provided in Config - Metadata API check - > In this for Derby ALWAYS > SET TO TRUE, and for > anything else, set based on API return value. In > case of exception set to > FALSE. > 3) Also for existing test cases - default TRUE will > be assumed as they run > using Derby and will not fail > 4) For PostgreSQL - this approach will work as > Metadata API returns FALSE > for JDBC 3 compliant driver > 5) In case there is any driver used which is not > JDBC 3 compliant and the > API is absent, then > it will again be caught as exception and value set > to FALSE. > > Please see if there are any further places for > modification in the above. > > Regards, > Amita > > On 7/24/07, Ron Gavlin <[EMAIL PROTECTED]> wrote: > > > > Hi Amita, > > > > Since DAS has JDK 1.4 as a requirement and the > JDBC 3.0 APIs are built > > into JDK 1.4, isn't it sufficient to interpret a > JDBC 2.0 driver throwing > > a exception from supportsGetGeneratedKeys() as a > false. Also, since the DAS > > is currently a pre-1.0 release, I don't think our > solution needs to be > > driven by backwards-compatibility or whether test > cases get broken or not. > > From my perspective, the default case (the absence > of the attribute) should > > be driven by the JDBC driver's > DatabaseMetadata.supportsGetGeneratedKeys() > > value. The useGetGeneratedKeys attribute could be > explicitly set to true for > > cases like Derby where the driver's partial > support for this feature is > > sufficient for the needs of the DAS. In the case > of Oracle, they just > > started supporting getGeneratedKeys() in Oracle > 10g R2. It is not supported > > in earlier versions of the database or drivers. > So, using the > > DatabaseMetadata-driven approach, the DAS should > be able to support all > > Oracle versions out > > of the box with no special config attribute. In > the future, hopefully > > Derby will implement full getGeneratedKeys() > support and thus would not > > require special configuration within the DAS. My > two cents... > > > > - Ron > > > > ----- Original Message ---- > > From: Amita Vadhavkar <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED]; > [email protected] > > Sent: Tuesday, July 24, 2007 8:56:36 AM > > Subject: Re: Flexibility in supporting JDBC's > > Statement.RETURN_GENERATED_KEYS in RDB DAS > (JIRA-1417) > > > > Hi, > > Below are some details about the solution for > JIRA-1353. > > Please review the patch. > > > > http://issues.apache.org/jira/browse/DERBY-242 - > indicates that for > > 10.1.1.0, > > > > DatabaseMetadata.supportsGetGeneratedKeys() > returns false. Also, checked > > that for the current Maven Repo's Derby version > (10.1.2.1) same is > > happening. > > > > DatabaseMetadata.supportsGetGeneratedKeys() is not > available in JDBC 2.0. > > (We can catch exception if it is thrown in the > supports...() , but we can > > not detect > > cases like above - Derby) > > > > So, using > DatabaseMetadata.supportsGetGeneratedKeys() (when > config > > attribute > > is not set) > > may not be reliable in all cases. > > > > To keep the fix simple and also not to break > existing test cases (which > > assume default > > TRUE), the following is changed in patch > > > > 1) New <Config> attribute > > <xsd:attribute name="useGetGeneratedKeys" > type="xsd:boolean" > > default="true"/> > > > > 2) Default to TRUE - so old test cases and old > configs continue to work > > > > 3) Remove vendor name hardcoding logic to set flag > useGetGeneratedKeys > > > > So, in effect, with this patch (JIRA-1353) user > will get an option to pass > > FALSE, when it is > > sure that the dbms driver in use does not support > this feature. Thus, > > instead of hardcoding vendor names (without driver > versions), the > > responsibility is given to user to pass FALSE when > needed. > > > > Have tested this fix on Derby, DB2, MySQL and > PostgreSQL. Also, new > > testcases (6) added - CheckSupportGeneratedKeys > > > > example Config XML using the above attribute (say > for PostgreSQL), the XML > > will look as > > > > > below-------------------------------------------------------------------------------------------- > > <Config > xmlns="http:///org.apache.tuscany.das.rdb/config.xsd";; > > useGetGeneratedKeys="false"> > > </Config> > > > > > -------------------------------------------------------------------------------------------------- > > User will need to pass the Config during creation > of DAS instance. > > DAS.FACTORY.createDAS(config, getConnection()) > > or > > DAS.FACTORY.createDAS(config) > > or > > DAS.FACTORY.createDAS(InputStream > configStream) > > > > The value of the attrib can be true/false. And > Driver may/may not support > > GeneratedKeys. > > Based on this, following situations can arrive- > > > > A> Driver supports GeneratedKeys > > 1]Table is created with one column having > GENERATED ALWAYS AS IDENTITY > > clause, > > Irrespective of value of useGetGeneratedKeys flag, > insert command will > > succeed > > > > true flag value - insert.getGeneratedKey() will > return key value > > > > false flag value - insert.getGeneratedKey() will > throw RuntimeException - > > "Could not obtain generated key!" > > > > 2]Table is created with no column having GENERATED > ALWAYS AS IDENTITY > > clause, > > Irrespective of value of useGetGeneratedKeys flag, > insert command will > > succeed > > > > true flag value - insert.getGeneratedKey() - how > should it behave? In case > > of Derby it is returning wrong results. > > > > false flag value - insert.getGeneratedKey() will > throw RuntimeException - > > "Could not obtain generated key!" > > > > B> Driver does not support GeneratedKeys (say > PostgreSQL) - tested with a > > test client - > > 1]Table can be created with no column having > GENERATED === message truncated === --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
