[Dev] Object persistence merits, and questioning assumptions (Re: [Dev] ZODB is not a Storage Technology)

[Michael R. Bernstein]

On Sun, 2002-11-03 at 14:20, Eric Gerlach wrote:
>
>  At 01:36 PM 03/11/02 -0800, David McCusker wrote:
>  >
>  > Eric Gerlach wrote:
>  > >
>  > > That would be closer to what I intended, but I still think we
>  > > shouldn't bind ourselves to particular technologies until we know what
>  > > we need them for.  I can cite some hilarious post-mortem comments on
>  > > projects that have failed because they chose a technology before they
>  > > knew that it was what was needed.
>  >
>  >However, the general idea of transparent object persistence is a good
>  >idea, and might be what is wanted without committing to a specific way
>  >of doing it.  I thought I'd understand the context better under Python
>  >if I heard more about how ZODB does it.  I could also go study it online
>  >elsewhere, but other folks here wouldn't hear informed commentary.
> 
> I agree with you that transparant object persistance is good.  However, I 
> don't see what the particulars of ZODB have to do with it.  If I understand 
> the area properly, most object persistance systems have basically the same 
> semantics.  If that's true then it doesn't matter what system we 
> choose.  As far as I (a user and possible developer) am concerned, I'm not 
> concerned with the internals of ZODB until I know what the need is.  Heck, 
> it's possible to write our own object persistance system... why not do that?

Well, to my mind, Python + object persistence == ZODB. Unless Chandler
has some requirements that are not met by a general purpose transparent
persistence mechanism for Python objects, there doesn't seem to be a
reason to develop a new persistence system from scratch.

> To make a non-ending with a few questions: Who says we need object 
> persistance in the first place?  Why not a traditional relational 
> database?  Why not an abstract linking datastore?

Well, that is a good question, but I'm probably not the person to answer
it, as I don't know what Chandler's actual requirements are either.

However, I can give you some of my thoughts on the relative merits of
object persistence.

I'm a Zope developer, and Zope's built in object database (the ZODB) has
always seemed to me a much more 'natural' way to develop applications
than dealing with the impedance mismatch of mapping data in and out of a
relational database to classes in a data model. When you're using
transparent persistence, the data storage part of your application
effectively disappears as a development issue.

Storage requirements remain as a *deployment* issue, but you should be
able to switch the storage details out without changing any of your
application code at all.

Essentally, if you're programming in an object-oriented language, why
would you want to deal with anything but objects unless you have to?

(I can't comment on object persistence vs. linking datastores, as I have
no experience with the latter)

Anyway, as far as questioning assumptions goes, the only assumption I've
made is that the folks at OSAF had good reasons for selecting the ZODB.
We don't yet know what assumptions and requirements exactly led them to
their choice, and until we do, I'm willing to spend some time discussing
ZODB specific implementation details.

While we're at it, should we also be questioning the choice of Python as
a development language?

Cheers,

Michael Bernstein.