Since we are talking about inprovements to <SQL> I would like to add two more things:
1) Attributes similar to <exec>'s "os" attribute. Which will execute the task only if the database is the one expected. Something like: <sql .... rdbmsvendor="oracle" rdbmsversion="8.1.6"> this will allow having different versions of files depending on features of a particular vendor. For this I was planning looking at DatabaseMetadata once the connection is made. 2) An attribute "onerror='continue'" the possible values being: continue, stop, abort (default when autocommit off). This is very important when recreating schemas since stupid SQL does not have a "create or replace table" command. So one needs to "drop" and "create" and what do you do the first time? Any comments, improvements, etc before I embark on this? Jose Alberto > -----Original Message----- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 27, 2000 12:56 AM > To: [EMAIL PROTECTED] > Subject: Re: [PATCH] Print SQL to System.out or output file > > > >>>>> "JMS" == Julian M Savage <[EMAIL PROTECTED]> writes: > > JMS> The part I'm slightly concerned about is that I don't use the > JMS> DriverManager to get an instance of the driver, but instead > JMS> instantiate the driver using either the built in class loader or > JMS> the AntClassLoader depending on whether or not the user > JMS> specifies a classpath. > > I think the way you've done it is the easiest way around the > problem. I've been playing around with adding a classpath element to > <sql> myself yesterday and found why using DriverManager didn't work > by reading DriverManager's code. > > In getConnection, DriverManager checks the ClassLoader associated with > this call (using some native magic) and tries to load the Driver once > again using this ClassLoader. If the class loaded by the "calling" > ClassLoader is different from the one specified to registerDriver, the > Driver is omitted. Comments indicate that this is considered a > security feature. > > The ClassLoader associated with <sql> is the system class loader. So > if your Driver is not loadable by the system class loader, > DriverManager will skip it. > > The solution I came up with involved a helper class that wrapped the > call to DriverManger.getConnection and loading this class via the > AntClassLoader so the "correct" ClassLoader would be calling the > method. Calling Driver.connect directly seems a lot clearer and easier > to grasp. > > I've slightly modified your patch to use Class.newInstance instead of > searching for a no arg constructor and invoking that. Hope you don't > mind. > > Stefan >
