On 12.Mar.2003 -- 01:58 PM, Geoff Howard wrote: > At 11:23 AM 3/12/2003, Torsten wrote: > ><snip/> > > > >>>But the .script file *is* actually a simple .sql script. > >>Yes, but as I remember it, wouldn't be appropriate to use as the > >>source in other DB's, but...
I think the main point is that we should have a clean SQL file that contains only the necessary statements to create the schema (all tables) and fills them with test data. The db.script has the disadvantages that it contains hsqldb specific internal aspects (it will even log connections!). Ideally, such a file would contain some comments as well, helping to understand the hsqldb specific syntax e.g. types, constraints, and autoincrements.
However, another possibility is to call org.hsqldb.util.ScriptTool from ant and connect to a hsqldb file: This would use a JDBC URL like jdbc:hsqldb:path/to/database/file like:
<java classname="org.hsqldb.util.ScriptTool">
<arg value="-url jdbc:hsqldb: -database path/to/database/file -batch -script script.sql"/>
<classpath>
<pathelement location="hsqldb.jar"/>
</classpath>
</java>
Yes, this is exactly what I was hoping existed with hsql. Hopefully it doesn't take very long to run...
<snip/>
> BTW - there would need to be some logic to determine during the database
> build whether the hsql block was installed (and it would need to have been
> processed first, right?) before attempting to merge this script with a file
> created by the hsql block. Or am I missing something?
Well, I don't see anyone use the embedded hsqldb used for anything else than the samples, so, why not put it into the hsqldb block. Don't get me wrong, I really like hsqldb, it's cool, small, fast and has some nice features. It does have its uses. It's just that I wouldn't want to start, stop my database server together with Cocoon in a real setup. That would render the approach of a database ridiculous.
That's probably true. Where then does script.sql (as referred to in the ant snippet above) go?
It seems wrong to put it in the hsql block (because it's specific to the db samples). So I guess in the db block. That makes the hsql block build (presuming that's where the hsql script call goes) depend on the database block, which is fine as you point out. Am I right that "block" dependencies are not dealt with yet, since we don't really have blocks but sub-builds called "blocks"?
Geoff
Chris.
--
C h r i s t i a n H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
