ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <JFernan...@viquity.com>
Subject RE: [PATCH] Print SQL to System.out or output file
Date Wed, 27 Sep 2000 19:54:50 GMT
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:bodewig@bost.de]
> Sent: Wednesday, September 27, 2000 12:56 AM
> To: ant-dev@jakarta.apache.org
> Subject: Re: [PATCH] Print SQL to System.out or output file
> 
> 
> >>>>> "JMS" == Julian M Savage <jsavage@fisci.com> 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
> 

Mime
View raw message