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...
Can you remember why? I haven't really looked closer into it.
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.
cool :)
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.
ok :)
<snip/>
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
Did understand that :)
<snip/>
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.
(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 :)
cheers -- Torsten
