Object Database (ODBMS) for Python

[Patrick K. O'Brien]

"Paul D. Fernhout" <pdfernhout at kurtz-fernhout.com> writes:

> Patrick-
> 
> I think based on this and your other posts I now understand better
> where you are coming from. Thanks for the explainations and
> comments.
> 
> To try to restate (and better justify) what I now think I see as
> your point of view on this transactional API issue, let me present
> this analogy.
> 
[Analogy snipped]
> 

Your analogy is absolutely correct.  A PyPerSyst transaction
Class/instance follows the Command pattern.  In fact, they were
initial called commands, and later renamed to transactions to
emphasize the fact that the actions taking place inside the command
needed to be atomic and leave the database in a consistent state (half
of the ACID properties needed to be a reliable database).  PyPerSyst
itself provides the isolation (the engine provides this) and
durability (storage provides this).

> To step back a minute, in general, a transactional development
> methodology is in a way a step up from the random flounderings of
> how many programs work, with code that changes the data domain
> potentially sprinkled throughout the application code based, rather
> than cleanly specified in a set of Command or Transaction
> subclasses. So you are sort of proposing generally a step up in
> people's understanding and practice of how to deal with applications
> and persistent data.

Yes!  And I love how you describe this - random flounderings.

> Does this sort of capture an essential part of what you are getting
> at here with your PyPerSyst application architecture development
> strategy? If so, I like it. ;-)

Absolutely.  And I'm glad you like it.  Now if only I had a perfect
model for guaranteeing the integrity and consistency of the state of
Python class instances, we'd be set.  Well, actually, I've got some
ways to do that, I just don't completely like them.

> P.S. The Pointrel System supports abandoning in process transactions
> by sotrign all the data it changes long the way, and being able to
> roll back to this state. But, with an object database as you have
> outlined it, I think this would naturally be a lot more complicated
> -- although perhaps you could adopt the "undo" and "redo" aspect of
> Commands (including stashing the old objects somewhere in case of a
> redo...)

I'm not sure we'd be able to easily support undo and redo in a
multi-user environment.  For a single-user application, this should be
easy.  And I'll probably eventually build in mechanisms to support
this.  But multi-user adds a few complexities.

Commit and rollback would be nice for complex transactions that change
a lot of state where your ability to guarantee the success of those
changes, or test the success as a pre-condition, is difficult.  The
easiest approach, which Prevayler is implementing, is to always have
two copies of the database in memory - one to try out a transaction
and see if it completes, the other to receive only transactions that
successfully completed on the tester.  But that approach doubles the
memory requirements, and we already have high memory requirements
since we keep the entire object graph in memory.  But the beauty of
this approach is that it is simple and foolproof.

Another approach would be for each transaction to keep mementos of
objects that get changed, so they can be restored if an exception is
raised at some point during the transaction.  But I think that will be
too complex and too much to expect from transaction writers, unless I
can come up with support for that in PyPerSyst that makes it easier.

Anyway, just some more thoughts.  Good talking to you.

-- 
Patrick K. O'Brien
Orbtech      http://www.orbtech.com/web/pobrien
-----------------------------------------------
"Your source for Python programming expertise."
-----------------------------------------------