IMHO, I would not use HSQLDB for anything that gets anywhere close to
production. It is not fully transactional, for instance it will not
hold a lock correctly after update. (doesn't support read committed).
from http://hsqldb.sourceforge.net/web/hsqlFAQ.html#FAQ (at the bottom)
"HSQLDB support only READ UNCOMMITTED isolation level when queries
are made from your Java program."
If you want embedded, use Derby, which is transactional and does
support read committed. We have been running a Continuum instance or
Derby for 2 years now, building about 20 projects with only a few
maintenance problems, so its good for small scale production.
So if you are thinking about a DB backend..... but your original
question was about populating the contents of the store with some
additional information ?
If its a DB backend, then a SQL script would make sense, its easy to
write a SQL loader ?
If its still to be an XML file, then the simple thing is to edit the
XML file (provided there isn't too much data).
As a general ping, I am still working on a DB implementation of the
social services that will support Derby and most other DB's, source
code is at https://source.sakaiproject.org/contrib//tfd/trunk/social-
db/ only because its somewhere I have commit to. The license if not
stated is Apache2. The unit tests is contains fills the DB with a
dataset of people and all other parts of the datamodel. I am also
thinking (but not doing anything yet) about implementing a JPA
version of this.
Ian
On 20 May 2008, at 02:52, David Primmer wrote:
From scanning the docs quickly, HSQLDB has a native storage format of
csv that can directly attached without import or export
http://www.hsqldb.org/doc/guide/ch06.html there are some caveats with
this format and there are quite a few ways to run the database (memory
only, in process, cached etc.) and I'd defer to someone with more
experience.
davep
On Mon, May 19, 2008 at 6:24 PM, Jun Yang (杨骏) <[EMAIL PROTECTED]>
wrote:
On Mon, May 19, 2008 at 6:18 PM, Dan Bentley <[EMAIL PROTECTED]>
wrote:
Maybe we could keep the data in some plain text format and then
just have
scripts that can weave it into the different formats as
required? This
might be easiest for ensuring that there is only ever one primary
source
and
different versions don't have to be maintained?
Agreed. How about CSV (with first line containing column/property
names)?
-Dan
Jun
On Mon, May 19, 2008 at 9:15 PM, David Primmer
<[EMAIL PROTECTED]>
wrote:
I have some updated data people, social graph, activities, that I'd
like to add to shindig but I'm wondering the best way to store
it and
work with it. Anyone have a suggestion? I'd like to replace the
state-basicfriendlist.xml file with something that's easier to edit
and work with that could be checked into shindig. Some suggestions
from the summit were http://www.hsqldb.org/,
http://db.apache.org/derby/ and http://www.sqlite.org/, the latter
being c-based.
I'm primarily interested in supporting the java rest api so hsqldb
sounds best but I'm sure the other implementations would like to
use
the same source data and may want something with more runtime
availability. Maybe we could store the seed data in multiple
formats
for seeding a few different small database engines but we should
start
with one.
I'd like to avoid non-embeded stuff like MySql.
There's been a request not to have the database engine included
in the
shindig jar. We'd have to design the maven rules to generate
alternate
binaries. Here's the maven rule to add hsqldb:
<dependency>
<groupId>hsqldb</groupId>
<artifactId>hsqldb</artifactId>
<version>1.8.0.7</version>
<scope>test</scope>
</dependency>
davep
