Mario Ruggier wrote: > I have looked over schevo's duru.py. Apologies in advance if I get things > wrong here... I only have a small amount of time to respond, so I'll try to answer some of your main questions below. [snip] > Looking over duru.py, i can throw out some examples (i may have understood > things very badly here): > > - "Container visibility": Schevo seems to "hide" away the container > (extent) from the client. Moellus makes it explicit, with the intention > that you may want to add custom behavior for specific containers, and how > you would go about doing it is obvious and natural. Schevo does expose the container, and allow for custom behavior, but perhaps in a more controlled and slightly less obvious way. There are a number of reasons for our approach that I don't have time to explain, but the driving force is data integrity, which must be preserved. > - "Predominiant feeling: relational or OO": Schevo seems to be trying to > respect, in spirit, more the terminolgy and data structures of the > relational world True - I've intentionally used relational terminology, even though Schevo goes beyond some of the "rules" of relational theory. As for data structures, those are implementation details. Which is supposed to be true in the Relational model as well - sort of like duck-typing - as long as it looks and acts relational it doesn't matter how it is implemented under the covers. > - "Persistent Objects vs. Entities": This may be similar to previous (and > I may be totally off mark here) -- am I correct in my suspicion that > Schevo stores an entity "in chunks across differnent structures" as > opposed to a simgle persistent instance? When you load an entity, is it > simply unpickling it, or does it involve also "initialising" an object? Prior to this Rebel branch, we pickled instances. Now, we are using Duru as a pretty low-level storage structure and "initializing" new objects as needed. In a way, we've simply done our own pickling and unpickling, rather than fight Python's mechanisms to support schema evolution and object migration, another very important area of focus for Schevo. > And so on... I understand that this could be a long discussion and we may > want to take this offline. > > Again, forgive me if I have misundertood the first scanning of duru.py. I don't think you misunderstood duru.py, but that file only tells a small part of the Schevo story - you'd have to look at the rest of the source code for that. And app developers don't do much with duru.py directly, instead using instances of Entity, Extent and Transaction subclasses. >>Watch out! A predecessor to Schevo was bdoz (bulldozer), an attempt to >>merely make ZODB easier to use. ;-) > > Wow, but it had a cute enough name !! > Why did it fail? I decided that ZODB was too big and complex. When Prevayler for Java came out I was attracted to it and developed the Python version, called Pypersyst. The work on the relational model stuff then split from Pypersyst and was moved to a new project, named Schevo. Now we are working on a branch of Schevo specifically for Durus. We'll probably add support for ZODB and Pypersyst, but Durus is our target for now. -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevo http://www.schevo.org Pypersyst http://www.pypersyst.org