JIRA-1353 provided the fix and JIRA-1417 may not be needed
On 7/25/07, Ron Gavlin <[EMAIL PROTECTED]> wrote: > > 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] > >
