On Monday 19 May 2008 14:47, Matthew Toseland wrote: > On Monday 19 May 2008 11:34, Matthew Toseland wrote: > > On Sunday 18 May 2008 19:44, Ian Clarke wrote: > > > > > > Looking at the manual, it looks like Perst operates at a lower level > > > than db4o - you need to manually create and maintain indexes. This is > > > closer to the Java collections API, which could be good because its > > > more familiar, but it leaves more opportunities for the programmer to > > > screw up, which is bad. > > > > IMHO we will get better performance and fewer screwups from a more familiar > > API. > > > > > > My preference for db4o is based mainly on my familiarity with it, the > > > fact that it is more widely used, and the fact that it superficially > > > appears to have a more credible company behind it. > > > > > > None of these is a solid justification for choosing one option over > > > the other, but they all suggest that db4o is the way to go. > > > > We should, as bback suggests, test Perst, see what happens when it runs out > of > > disk space. I will look into it soon. > > Completed testing. Perst fails gracefully on running out of disk space in > between writes. The database is readable after the failed commit, and if I > take away the bigfile occupying all the disk space, we can even write to it. > > How about we go with Perst?
One big disadvantage for Perst: no online backup! No transactions may execute while backup is in progress. :( Generally speaking Perst is significantly lower level than db4o. This isn't necessarily a bad thing, it allows fine control and possibly better performance... For example, all persistent objects in Perst must extend Persistent (1 pointer 2 ints overhead), or implement IPersistent (which involves copying code from Persistent)... or implement IValue, which allows an inline value to be stored with the parent object, or java serialization (but in that case the object must not refer to any persistent objects). Whereas db4o can persist anything (using bytecode rewriting, of course). This isn't automatically a good thing: given that classes may change, even with schema evolution (which iirc both support), we need to be careful with persistent classes. And of course, Perst uses explicit indexes, whereas db4o uses queries. Thoughts? IMHO backups are an important feature, and they'd probably have to be hot backups for our usage... but then, not corrupting on running out of disk space is important too!
pgp0aNOECY5Zi.pgp
Description: PGP signature
_______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
