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>
Thus we have
+ clean separation of schema / data from hsqldb internal data
+ automatic initialization without much trouble
> >>The only reason approaches like this would have any value would be to
> >>facilitate using other than hsql db for the samples. If I already have
> >>mysql installed, I may
> >>choose to exclude the hsql block.
> >
> >Don't understand this. Why would you want to try the samples in your db?
> >I don't really see why we should take the burden on making sure that our
> >sql creates all tables and data successfully on database X just because
> >the user wants to run the samples on his database out of the box.
Absolutely.
> >(I mean it's very basic sql - it should not. But I wouldn't take a bet on
> >any datatype or the primary key definitions. I've seen too much crap out
> >there;)
:-)
> >Don't take me wrong. I am not against this - but atleast *I* just cannot
> >see the real value yet. Please tell me :)
>
> It's OK, I don't even know if I'm for it! ;) Seriously, I guess Chris has
> echoed that it has been a frequent request, and it seems reasonable to
> me. But admittedly that's not a very compelling case for a lot of work. I
> see two separate questions:
>
> 1) Should we take steps to make it easier to run the samples in another
> database.
> 2) Should we automate it.
>
> I'd say the first is worth some effort, and the second probably not if they
> can be separated.
>
> So, if we have a samples.sql that gets merged into db.script via ant for
> the database block using hsql by default and can also be used to manually
> create the appropriate tables and sample data in your db of choice, that
> would accomplish #1 while stopping short of #2.
>
> Does that KISS?
>
> 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.
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
