|
[
Permlink
| « Hide
]
Robert Kasanicky added a comment - 24/Mar/08 02:03 PM
How about simply providing an example how to configure hsqldb to use disk-based tables? I don't see a benefit in having text file daos compared to bundled database (be it hsql, derby or h2).
I agree with Robert. It doesn't get any easier than hsqldb as far as relational database and I'm not sure the advantage of a file dao.That being said, I do know that the resources used with persistence in projects like EMF use XML storage in an XMI format. I personally don't think its much easier than a db but it supplies the necessary behavior of query support through uri's etc. Is that what you were thinking?
I think HSQL files are a great idea. Robert: can you look into it a bit and post back a patch for the samples, perhaps? I think the key questions are:
1) are the files human readable? 2) can they be archived and uploaded into a "real" database as a migration option? The HSQL files I've seen are basically a log of database operations (CREATE, INSERT), so they are human-readable. I'm not sure how easy the uploading to "real" database would be given the discrepancies in SQL syntax.
Anyway, I'll dig into this post 1.0. Configuring HSQL to use files instead of pure in-memory mode is trivial - just replace "mem" with "file" in the uri and HSQLDB will create the files in the current directory (catch - remove the initializing datasource wrapper after first run).
However things don't really work as expected. Both STEP_EXECUTION and JOB_EXECUTION entries have status 'UNKNOWN' although the job ran successfully. The entry for step execution is overwritten for each step i.e. eventually there is entry only for the last step. When I tried running second multi-step job, it suddenly had entry for each step (but still all statuses 'UNKNOWN'). Third job didn't create any entry although I ran it several times. Any ideas what might cause the database to behave so unpredictably (it works fine when run as standalone server)? I'll take a look at Derby and H2, one of them will hopefully just work. I tried switching to embedded Derby (we already provide everything necessary) and it works well (with the exception of
@Dave: if proper shutdown was the issue shouldn't we have the same trouble using 'mem' protocol (e.g. restart sample wouldn't work)? No, that wouldn't be an issue because the VM is never stopped (the database is always active in all tests). It isn't a "real" restart, in the sense that the VM stops and then starts again. It's a "simulated" restart.
(N.B. you can switch to embedded Derby by commenting out a line in data-source-context.xml: <!--import resource="alt-data-source-context.xml" /--> .) No, that wouldn't be an issue because the VM is never stopped (the database is always active in all tests). It isn't a "real" restart, in the sense that the VM stops and then starts again. It's a "simulated" restart.
(N.B. you can switch to embedded Derby by commenting out a line in data-source-context.xml: <!--import resource="alt-data-source-context.xml" /--> .) Dave,
you were right about the proper shutdown - I tried adding a DisposableBean that issues "SHUTDOWN" to the hsql database and everything works fine that way. I think we can close this issue? And maybe start a new one to document how to setup embedded database.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Closed
Major
Provide text file based implementation of Daos
