okay... sounds good. So, we can still have the <setting> attribute that states compatibilit with using 2 or 3 as values (eventually 4 as well). But, if you are not explicit we will set it by using class.forName and finding out whether a jdbc 3 specific class exists and setting the compliance on our own. Does that sound good?
Brandon On 6/11/05, Larry Meadors <[EMAIL PROTECTED]> wrote: > I agree with Sven, we can check for the existence of > classes/interfaces/methods that are new in each release to auto-detect > the JDBC version if the settings did not provide a value. > > Larry > > On 6/11/05, Sven Boden <[EMAIL PROTECTED]> wrote: > > > > Very personal preference.... auto-detection, but tag can override if > > required. > > > > Regards, > > Sven > > > > > > On Sat, 11 Jun 2005 00:05:41 -0600, you wrote: > > > > >Hey guys, > > > > > >I'm reposting this because i'm not sure it got out with all the email > > >hiccups over the last day. I'd really like to get some feedback on > > >this. It will help us to move forward with adding jdbc 3 support... > > > > > >We need to start supporting some jdbc 3 functionality. I was thinking > > >we can use the <settings> tag and add a compatibility attribute to it. > > >The default would be 2 but could be configured to support 3. Then when > > >we add support for savepoints, generated keys, etc... we can throw a > > >sensible exception when someone tries to use jdbc 3 functionality in a > > >jdbc 2 compatibility mode. > > > > > >My question is, do we want the support to be explicit with the setting > > >tag? or do we want to use an autodetection means? > > > > > ><settings ... [compatibility="3"]/> > > > > > >thoughts? > > > > > >Brandon > > > > >
