[Dev] Object persistence merits, and questioning assumptions
(Re: [Dev] ZODB is not a Storage Technology)
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
>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?
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>Open Source Applications Foundation "Dev" mailing list
More information about the Dev