[Dev] ZODB is not a Storage Technology (Re: other formats )

[Jeremy Hylton]

>>>>> "EG" == Eric Gerlach <egerlach@canada.com> writes:

  EG> At 03:28 PM 03/11/02 -0800, Kevin Altis wrote:
  >>> At 01:09 PM 03/11/02 -0800, David McCusker wrote:
  >>> >Does anyone want to lecture on how ZODB works inside?
  >>>
  >>> Just a quickie: At this stage, does it matter?
  >>
  >> From a design standpoint it probably does. I'm not a ZODB expert
  >> by any means, but it is my understanding that Python pickles are
  >> what ZODB stores.  I'm not sure how this changes as you try and
  >> use a Berkley DB as a backing store, but it does bring up a big
  >> design point.

  EG> I sort of agree... I think that experience with data stores will
  EG> help in thinking of requirements for the data, but focusing on
  EG> one implementation restricts your view.  My point in
  EG> rhetorically asking whether or not the internals of ZODB matter
  EG> was to point out that the internals of the data store technology
  EG> really don't matter until you know what the data store is
  EG> required to do.  Once that is known, then it matters.

I may just be repeating what others have said, but I think it's
helpful if you think about ZODB as a persistent object system and not
a data store.  ZODB can use a variety of backend storages, but the API
it exports isn't a data storage API.  A typical ZODB application is
structured around transactions, not about load & sotre.

I've just skimmed the recent list traffic, and I don't have a strong
sense for what questions are important at this point in Chandler
development.  It seems to me that one of the chief advantages of
persistent object systems in general and ZODB in particular is that
you don't have to worry much about the data storage layer.

Perhaps I don't understand what you mean by data storage issues.  The
discussion has been quite abstract so far.  I'd be happy to answer any
questions you've got about how ZODB works.

Jeremy