Hm... I see. So it's enough to just copy the sql script into the
WEB-INF/db location. I'll take look...

I was just getting ready to see if there is an ant call to process a sql script over jdbc (I'm sure there is, just don't know ant well enough) but I'd make slow progress now as I'm very time limited.


Well, but when do you wanna call the target?
The hsqldb would need to be running.


Doh!  Well, it could be a stand-alone target with a note on the
database samples page that it should be run while cocoon is up.

HSQL can be run separately from cocoon, of course and could be started up
from the build (with a custom task?).

aaaah... no


For now, though for purposes of reviving the samples quickly it may be as easy as re-commiting a new db.script into the database block with the changes in it.

IIUC hsql uses this file as its persistent store of data - when you shut down, it gets overwritten with what is in memory. So, if you make changes to the file,
then restart cocoon to reload the changes, they disappear. It was awkward for me trying to contribute (read: I lost changes a few times and am still getting over it emotionally ;) ) but that's not happening much.

...and I assume it's get loaded when it comes up. So all we need to do is to put a file into the webapp (at the right place) so it gets loaded as it where shut down before, right?

<snip/>

But since this is only used for the "personal" datasource it doesn't
make any sense all to have it configurable in the properties. It's just
for the example database. Let's KISS :)

So if noone is really keen on those properties I'll remove them from the
build. No need to filter then.


Christian's got another thread on this.  Seems fine to me, for
what that's worth.

excellent -- Torsten



Reply via email to