Return-Path: <jalberto@cellectivity.com>
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Delivered-To: mailing list dev@ant.apache.org
Received: (qmail 52617 invoked from network); 27 Feb 2003 12:07:19 -0000
Received: from unknown (HELO london.cellectivity.com) (212.18.242.163)
  by daedalus.apache.org with SMTP; 27 Feb 2003 12:07:19 -0000
content-class: urn:content-classes:message
Subject: RE: creating pl/sql package in sql task,
 only part of package  lo aded
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Thu, 27 Feb 2003 12:07:17 -0000
Message-ID: <747F247264ECE34CA60E323FEF0CCC0C0F50C0@london.cellectivity.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: creating pl/sql package in sql task,
 only part of package  lo aded
Thread-Index: AcLc9qnuFuo9GrbqTHaakw2ehN4/pwBX5hOw
From: "Jose Alberto Fernandez" <jalberto@cellectivity.com>
To: "Ant Developers List" <dev@ant.apache.org>
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Rob,

I am saying two things:

1) SQL Blocks (as you call them) are already supported by defining a =
delimiter other=20
than ";" (i.e., delimiter=3D";;" is what I use)*

2) When you are loading big things like blocks into the RDBMS it seems =
useful
to keep the formatting as is. Hence, we should add the new =
"keepFormating" attribute.

The second can be achieved quite simply in the current <sql> code. The =
first is already there.

*There is an additional thing that eventhough not necessary could be =
nice for Oracle PLSQL
users, that is to support the idea of a line containing just the =
delimiter as the valid delimiter.
To be able to specify that the delimiter in the middle of a line should =
not count as such. [confused already :-)]

We could add another attribute "lineDelimiter=3Dtrue" to achieve that. =
So to process PLSQL files valid in sqlplus
You would say:

 <sql driver=3D"${db.driver}"
 	print=3D"true"
 	lineDelimiter=3D"true"
 	delimiter=3D"/"
 	keepFormating=3D"true"
 	url=3D"${db.url}"
 	userid=3D"${db.userid}"
 	password=3D"${db.password}">
         <fileset dir=3D"${db.sql.dir}" casesensitive=3D"no">
                 <include name=3D"**/*.sql"/>
         </fileset>
 </sql>
=20
the defaults would be lineDelimiter=3Dfalse, keepFormating=3Dfalse, =
delimiter=3D";" (for backward compatibility).

Suggestions from others on attribute names are appreciated.

Jose Alberto
> From: Anderson, Rob H - VSCM [mailto:Anderson.Rob@vectorscm.com]
>=20
> Jose, I think it is a good idea to include this functionality=20
> in the sql
> task. I am not sure how we would alter the usage of the sql=20
> task. You are
> suggesting we have a keepFormat attribute, correct? However,=20
> my task is
> bassically meant to deal with a sql block, and does not care about
> formatting. In other words, formatting is always kept,=20
> comments and all.
> That being said, I would suggest that we simply have a boolean flag to
> indicate whether or not to process the sql, or file(s)=20
> containing sql, as a
> block. For example:
>=20
> <sql driver=3D"${db.driver}"
> 	print=3D"true"
> 	sqlblock=3D"true"
> 	url=3D"${db.url}"
> 	userid=3D"${db.userid}"
> 	password=3D"${db.password}">
>         <fileset dir=3D"${db.sql.dir}" casesensitive=3D"no">
>                 <include name=3D"**/*.sql"/>
>         </fileset>
> </sql>
>=20
> Then, to integrate this into the existing sql task I will=20
> move the statement
> processing part of the two tasks into two new methods, one of which is
> executed based on the sqlblock flag, which defaults to false.=20
> Thoughts?
> Suggestions?
>=20
> -Rob Anderson
>=20