It would be great if you could force a different exception in your investigation (e.g jdbc driver supports returning the generated keys, but the call gives back a different exception), and see what is the resulted behavior of your proposal.
On 7/10/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote:
That is right, I will also give it a try with some known rdbms dirvers, versions and list the results in JIRA-1417, and we will also analyze further for alternatives. I also, saw some relevant links related to JIRA-1416 (PostgreSQL...generated keys). [1] http://gborg.postgresql.org/project/pgjdbc/bugs/bugupdate.php?984 [2] http://archives.postgresql.org/pgsql-jdbc/2007-02/msg00074.php Based on [2], it looks like , server >=8.2 , has some support for auto gen keys in PostgreSQL. So, validity of JIRA-1416 will be based on the exact version of PostgreSQL, Regards, Amita On 7/10/07, Luciano Resende <[EMAIL PROTECTED]> wrote: > > Hi Amita > > Indeed we need a better way to handle this, my only concern with > this approach are the unknown side effects we can get if the exception > returned when you first pass the Statement.RETURN_GENERATED_KEYS is > not related to the JDBC driver supporting or not generated keys. > > On 7/9/07, Amita Vadhavkar <[EMAIL PROTECTED]> wrote: > > Hi, > > > > We are at present hardcoding some vendors (e.g. Oracle) in > ConnectionImpl to > > decide whether to > > use autogenerated key feature in preparedStatement. This logic is > subject to > > change > > as and when new features are supported by different databases and > different > > vendors. > > Instead, if we have a flexibility to check in the very first attempt of > > connection.prepareStatement(queryString, Statement.RETURN_GENERATED_KEYS > ); > > throws exception and based on that, if we can tweak the decision making > > flag useGetGeneratedKeys to true/false, then, at any runtime of DAS, > > "maximum once", there is > > a chance that exception will be thrown / caught and later all attempts > will > > follow > > correct syntax of connection.prepareStatement() as supported by the > current > > rdbms > > driver being used. Based on JDBC specs, the only exception possible > from > > connection.prepareStatement() > > is SQLException. > > > > This check can be introduced in ConnectionImpl.prepareStatement(). > > Thoughts? > > > > Regards, > > Amita > > > > > -- > Luciano Resende > Apache Tuscany Committer > http://people.apache.org/~lresende > http://lresende.blogspot.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
-- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
