<snip/>
That's why I wouldn't give up too easily on making the db setup work from a normal sql script. Currently we have the .sql out there, but I'm not sure it's up to date (though it looks like it), and if it's not used, it's certainly in danger of getting out of date at some point.
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...
Now that the samples are at least working again, how about considering some options for actually creating the samples "schema" from the .sql?
But we could split the cocoondb.script file into
cocoondb.setup + cocoondb.sql --ant--> cocoondb.script
that might be all we need.
So the schema is pretty much the cocoondb.sql file that could also be copied into the samples. Or do you mean a real "schema"?
Sorry, sloppy use of terms. I actually meant "table definitions and sample data" for the examples.
<snip/>
> Users could provide the dbconnection name, which would let them use hsql by default, or any other db they've already set up.
Sorry, I cannot find a good reason on reading the samples entries from an already setup db ;) Why would you want to do this?
Not sure we're understanding each other. I was proposing starting the hsql engine "blank" (as it was before you fixed it) and providing a means of creating the table structure for the samples and populating the samples data in it while cocoon runs (and presumably while the user is reading the database block samples page, following the "in order to use these samples" instructions that would then be necessary). One idea was to create them via pipeline (action, sql transformer, etc. - see Chris' email). Another would be to have a command line script (ant or otherwise).
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.
Geoff
-- Torsten
