[ZODB-Dev] basic operational documents?

[Jeremy Hylton]

>>>>> "DM" == David McCusker <david@treedragon.com> writes:

  DM> Jeremy,
  >> I know you're aware of the Wiki and, thus, probably the things
  >> that are linked to from it.  Are you looking for something that
  >> isn't advertised there?

  DM> So far I haven't seen a description of the feature I consider
  DM> most important and central to the ZODB architecture.  This is a
  DM> definition of how OIDS and object pointers are swizzled, and an
  DM> exact explanation of when this activity happens in response to
  DM> which methods being called.

(Just a brief weekend response.)

Jim's paper from the 8th Python conference and my slides from LL2 are
probably the best overviews of the key architectural issues.  I don't
know if I use the word swizzle on the slides, but the slide on Object
caching / identity covers it.

  DM> If you want, I can start keeping a running list of questions
  DM> about why ZODB might be doing.  But the list might be
  DM> distracting if in many cases ZODB doesn't ever perform an effect
  DM> and the question ends up meaningless.

It doesn't hurt to keep that list accessible on the web.  Even if we
don't end up answering all the questions, we might cover enough to
benefit both of us.  Improving the docs and implementors notes is a
goal for ZODB4, if not for the alpha release.

  DM> Today on a walk for exercise, I thought up a scheme that could
  DM> be used to figure out which object IDs ceased to exist after
  DM> aborting a db transaction, assuming the object IDs were minted
  DM> by the db, presumably in serial integer sequence.  Related to
  DM> that, I have a question about how ZODB allocates IDs where this
  DM> is stored in a db.

Each storage is responsible for allocating object ids.  There's no
special logic for object ids that never get used, because the
transaction that created the object was aborted.  Such a transaction
just leaves an unused oid.

Jeremy