Object Database (ODBMS) for Python

[Patrick K. O'Brien]

Jeremy Bowers <jerf at jerf.org> writes:

> On Thu, 28 Aug 2003 20:26:41 -0500, Patrick K. O'Brien wrote:
> >>>> u1.name
> > 'Bob'
> >>>> u1.name = 'Joe'
> > Traceback (most recent call last):
> >   File "<input>", line 1, in ?
> >   File "/home/pobrien/Code/pypersyst/entity/entity.py", line 94, in
> >   __setattr__
> >     raise AttributeError, 'Modifications can only be made by transactions'
> > AttributeError: Modifications can only be made by transactions
> > 
> > So, let's use a transaction:
> 
> So why *isn't* it a transaction? Unless you have a good reason not
> to, I'd suggest automatically "coercing" that into a transaction
> instead of throwing an error.

These are some of my reasons: 1) every transaction gets pickled and
logged before executed, so that the database can recover from a crash,
2) most of the other cool features depend on mutations passing through
the extent manager for each class, 3) transparent transactions only
seem like a good idea, 4) security is hard to enforce without explicit
boundaries (read the Twisted docs regarding Perspective Broker), 5)
explicit is better than implicit, especially when valuable persistent
data is involved.

> Give an indication in the docs about the performance issues if you
> like, but make the trivially easy case easy.

Performance has nothing to do with it, actually.  Integrity and
security are to blame.

> (I'm only really entering my maturity (IMHO) as a software engineer,
> but one of my rules of thumb for developing software for other
> people to use is that the API can ***never*** be too easy. Doing
> something hard may be a little tricky but if you can make the easy
> case still work, you're way ahead. And Python is one ass-kicking
> language in that regard; it's one of the reasons I love it so much,
> the APIs can be made so easy to use they sometimes fade into
> complete transparency, like "u1.name = 'joe'". (I've been focusing
> on how to write APIs for others to use, esp. in Open Source though
> it applies equally to any team effort, that will be successful,
> rather then ignored.))

I agree that APIs are very important, and I've worked very hard on the
API for PyPerSyst.  At the same time, everything has a tradeoff.  When
I gave up on the dream of transparent transactions, there were a lot
of benefits, and lots of other features fell into place.  Even though
I think PyPerSyst is one of the most elegant things I've ever coded,
especially in terms of the API, I'm sure it can be better.  So I
welcome suggestions for improving it.

If you can figure out a way to have transparent transactions, without
giving up on any ACID properties considered mandatory for a DBMS, I
would love to hear about it.  Have you worked with any other object
databases?

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