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

John Anderson john at osafoundation.org
Fri Nov 8 14:00:37 PST 2002


Michael R. Bernstein wrote:

>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.
>  
>
Having developed projects with and without transparent persistence, I 
believe persistence can save a huge amount of useless grunt work.

>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.
>
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
>Open Source Applications Foundation "Dev" mailing list
>http://lists.osafoundation.org/mailman/listinfo/dev
>  
>




More information about the Dev mailing list