On Oct 9, 2005, at 12:24 PM, Patrick K. O'Brien wrote:
>
>
>> 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.

Okay.  This part isn't any different from plain-Durus applications.

>
> 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

I think they mean that if A is persistent, and
you assign a value to an attribute of A, and then
do a commit, then you'll find the same value there
in the future.  It is transparent because
attribute assignment looks just like it does
when persistence is not being used.

> 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.

Right.  There are going to be different ways
of expressing those logical constraints and
on making sure that they are satisfied at
transaction boundaries.
>
>> 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.

That sounds like an alternative way, as I think Oleg described it
earlier,
of "taking notes" about changes to be committed in a transaction.
The plain-Durus way "takes notes" directly in the __dict__ and
changes the instance status to make sure that the changes are
written out on the next commit.