David Binger wrote: > > I think I understand. Schevo supports the automatic maintenance of broad > data constraints. This requires schevo applications to stick to a set of > higher level (higher than setattr) operations that modify a > transaction instance. > The advantage of this is that the set of objects seen by an application > always satisfies these constraints. Yes, exactly. > In our applications, we try not to have constraints between objects. > When they can't be avoided, we wrap those changes in methods that > maintain the constraint. For example, if a change in the name of A > requires > a change in an index on B, we only change A's name through a function > that also updates B's index. That works fine for us, but I can see > how others would be attracted to having automatic enforcement of > more formal constraints. Yes, again. The goal of Schevo is to make as much of this declarative as possible, leaving the application developer to focus on the few cases that are exceptional. > I assume that, in the execution of a schevo transaction, you do in > fact use automatic/transparent persistence. Right? Well, we call a single Durus commit or rollback for the entire transaction. And a transaction can be quite extensive. For example, the population of sample data into a new Schevo database is a single transaction - either every single object is created, or none are created. There is no limit to how many objects may be created, updated, or deleted, in the same transaction. In fact, database objects may be created and later deleted in the same transaction, such that they serve their purpose within the transaction but are never visible outside of it. To me this is the opposite of what most people mean when they talk about transparent persistence because they usually mean that some set of changes becomes persistent implicitly such that the application developer doesn't have to worry about them. Maybe that is okay in a trivial, single-user application. But beyond that I think a certain amount of care and attention needs to be paid to the boundaries of your transactions. After all, the database is supposed to reflect the constraints of the domain in question. Merely having stuff "survive" in the database is not enough. It also needs to be logically consistent every step of the way. > If I understand it right, applications that use schevo don't > actually, directly, set attributes on Persistent instances. > Is that right? That is correct. All changes (creates, updates, deletes) take place through transaction objects. The cool thing is that every Entity knows how to supply a default transaction that has the same set of fields as the entity it represents. So it mosly looks like you are setting the attributes of the instance, even if you aren't. And it is easy to override the defaults to introduce additional constraints. -- Patrick K. O'Brien Orbtech http://www.orbtech.com Schevo http://www.schevo.org Pypersyst http://www.pypersyst.org PyDispatcher http://pydispatcher.sourceforge.net