[ZODB-Dev] what appears inside zodb storage?

[Toby Dickenson]

On Thursday 19 December 2002 2:19 am, David McCusker wrote:
> I wonder whether someone can verify my current understanding of what
> appears inside a zodb storage like file storage.  (If other storages ha=
ve
> contents that differ substantially, this would be good to know in some
> detail.)
>
> I understand a storage contains mainly a collection of pickled objects,
> where each object has an oid,

each pickle has an oid and a revision id. In every storage today (afaik) =
the=20
revision id is the same as the transaction id in which it was written.

> and an index that maps oids to objects.

a map from oid to the current revision of that oid

(the name 'object' is a little ambiguous at storage level)

> In addition to this, there are transacted updates to the objects.

transactional updates to the map. pickles never change - they just get=20
superceded by new revisions in the map

> Maybe an updated object is updated by writing a new version entirely, a=
nd
> making the map cause the oid to refer to the new version while leaving =
the
> old one alone (without deleting it), so packing is needed to make stora=
ge
> smaller.
>
> So my theory is that a file storage contains pickled objects and a map =
of
> oids to those objects, and maybe old stale versions of objects, and a
> chained linked list of transactions that allow earlier views of the wor=
ld
> to be taken instead of the last one.



> When zope btrees are used and these are stored persistently (are they
> always stored persistently?) where are the btrees stored?

BTree nodes are themselves persistent objects, and are stored in the mann=
er=20
you describe above the same as any other object.

A new persistent object only gets written to storage if there is a refere=
nce=20
to it from another object which is written. This new object is 'discovere=
d'=20
when pickling the other object.

> My motivation for asking today is a desire for versions in Chandler tha=
t
> support synchronization and replication.  A simple transaction model
> (which zodb might have, but I don't know) need only have a way to indic=
ate
> which version of an object should apply for a given transaction.  It ne=
ed
> not make it easy to consult specific versions of an object.

ZODB assumes that all normal access is to the current revision. For examp=
le=20
old revisions are not cached.

> In a Chandler discussion this morning, we had half an idea we'd be
> journaling our object changes in a fashion independently of zodb in ord=
er
> to support our needs for synchronizing repositories that have different
> modified branches of some comman ancestor version.

If your application needs access to old revisions for application-level=20
purposes then it is a good idea for your application to maintain the old=20
revisions itself.

I hope this helps.

--
Toby Dickenson
http://www.geminidataloggers.com/people/tdickenson