cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: esql samples
Date Tue, 11 Mar 2003 17:49:46 GMT
At 12:33 PM 3/11/2003, you wrote:
>>>I wanted to look after the esql samples but found
>>>1) the hsqldb not being filled (where did we do this before?)
>>I noticed this a few days ago, but haven't had time to write about it.
>>I'm pretty sure from experiencing adding a new table to the demo a month 
>>ago that the hsqldb was not built automatically.  I had to modify the 
>>hsql running on my machine, and commit WEB-INF/db/hsql.script (or 
>>whatever) that was created when hsql shut down.  I could be wrong.  But 
>>that's what I remember.
>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?).

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.

>I think the copy into the db directory should do it.
>>>2) the jdbc url, user and password not being replaced
>>This i'm not sure about, but was it done by filter before?
>Yes it was. And the variables are already in the properties.
>As well the build.xml looks like it *should* work (on the first glance).
>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.



View raw message