I think the initial goal is to have a canonical data set that can be checked into SVN and that is easy for people to write unit tests against. I believe most of the databases mentioned here can be dumped with common tools to either CSV or a sequence of DDL and DML, the latter probably being more generally useful across a broad range of DB platforms including non-embedded ones as it should be WORA. I think for in-process testing during feature development I don't think transaction isolation should be an issue. I don't think any sane person would suggest using an in-memory Java DB for production. Given that we are Apache Derby would get my vote on principal.
Ian I think ALOT of people would love to have the essence of your work move into Shindig. I will have a look at what you've got and get back to you. 2008/5/20 Ian Boston <[EMAIL PROTECTED]>: > 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 >>>>> >>>>> >>>> >>> >
