David Binger wrote: > > On Oct 8, 2005, at 7:26 PM, Patrick K. O'Brien wrote: > >> IMNSHO the database should do these things automatically, based on a >> declarative syntax of the desired keys and indexes. That's what Schevo >> does. Here is a snippet from a Schevo schema: > > > I'm glad for that to be a possibility, but "should" is not the right word. You know, after I sent my reply I thought "Sheesh, I'm going to look like an overzealous asshole." So, I apologize for going overboard in my response, especially since this discussion is taking place on your list, not mine. And I especially feel bad because I have tremendous respect for all of you Durus folks and Schevo is benefitting from your terrific work. I'm just excited about how things are coming together for Schevo after years of hard work, much of which required me to ignore the conventional wisdom about what an OODB could and could not do. >> Why shouldn't the database do more, like enforce referential integrity, >> automatically maintain bi-directional links, provide cascading (or >> restricted, or unassigning) deletes, intelligent fields, enough metadata >> to support a dynamically constructed UI, etc? Schevo does. > > > I think it is great to have these additional features as a possibility for > applications that need them. When I think about the applications > we run here, though, I can't see any of these as needed. True enough. And Schevo favors a relational style of modeling. So if you wanted to stored something like RDF triples, you could probably do so using Durus but Schevo would be totally inappropriate. On the other hand, an awful lot of applications do need these features and quite often they are reinvented for each application. >> Automatic persistence is the wrong approach and is a waste of time and >> effort. Transactions as explicit objects is the right approach. You >> can guess which approach Schevo supports. ;-) > > > Please explain this. In a nutshell, Schevo application code does not set transaction boundaries. Instead, application code creates transaction instances, sets their field values, and asks the database to execute them. The database works with Durus behind the scenes to either commit or rollback as appropriate. So application code looks like this: tx = db.Person.t.create() tx.name = 'Fred' tx.gender = db.Gender.findone(code='M') new_person = db.execute(tx) There is quite a bit more to be said about Schevo transactions, but instead of doing it here I should really write some docs about them. The problem I see with automatic persistence and transparent persistence is that the level of granularity is usually too fine, which can often leave data in the database in an inconsistent state (from the point of view of database integrity rules, like unique keys and such). Having explicit transaction boundaries is better, and having explicit transaction objects is even better still. >> BTW, we are very close to a formal release of Schevo, which has been in >> stealth mode for about 4 years. In the mean time, feel free to get the >> code from our Subversion repository and ask any questions if you want. >> BTW, yte version that we are about to release uses Durus exclusively as >> its storage engine and it is working so well that we may not have a need >> to support ZODB, Pypersyst, or any other storage mechanism. > > > All good news. Again, you all have my deepest appreciation for having made Durus available and for doing such a great job maintaining it. Thanks for putting up with my occassional rant. :-) -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevo http://www.schevo.org Pypersyst http://www.pypersyst.org PyDispatcher http://pydispatcher.sourceforge.net