2008/5/20 Vasudeva Nori <[EMAIL PROTECTED]>: > 2008/5/20 Louis Ryan <[EMAIL PROTECTED]>: >> 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. > in-memory Java DB is not that useless though. > I have worked on two big installations using TimesTen in memory > database to maintain data in memory (in lieu of the rather slow EJB > caching mechanism) and TimesTen interfaced with Oracle to persist and > distribute data. Not sure if Derby is ready for primetime production > usage but it is going to get there soon. > > does anyone seriously use the samplecontainer code in production? It > must really be just for guideline. So, I would vote to have all > database flavors added to Shindig as samplecontainers - CouchDB,
I definitely don't think this last bit is a good idea. If we have implementations for all of them then we have to support all of them. Adding a new field would require updating tons of different backends - most of which wouldn't be used in prod. Let's just pick one, all agree, and go with it. And, as long as the db is easy enough for all of our users to run, then we should just delete the current xml state file stuff. One demo impl is enough :) > hsqldb, mysqldb and Derby of course. At the very least, having all > databases as samplecontainers will be useful for anyone interested to > pick the example samplecontainer and use it. >> >> 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 >>>>>>> >>>>>>> >>>>>> >>>>> >>> >> >
