Jim Fulton wrote:
An object may be in multiple collections or referenced in other ways. Even if an object is only referenced in a collection, it is not removed from the database until the next pack.
Somehow, I had the feeling that, while the object database allowed any containment structure, the Zope front-end itself follows a strictly arborescent model, so that *zope* objects are singly linked. Is this correct ? What is the morale of this constraint ? What about circulat references ? What will break if I use multiply linked objects ? For instance, I believe objects carry their ids, which are simultaneously their attribute name by their parent object. What zope code will break in case of object id mismatch ? If (suppose) I make sure that multiply linked objects are always stored under their unique id, by all their (therefore distinct) parents, what will break next ? How much of the problem is simply to make very sure the user can't make circular references ? Why don't objects fully acquire their id ? Or did I miss it ? Etc, etc, you know, questions are like rabbits.
(When an object is removed from the database during packing, it's record is simply removed. No method gets called on the object. Old objects don't die, they just fade away. ;)
The initial documentation mentions backwards time-travel as a supported feature of the object store. Obviously this feature competes with packing. Is there any plan to support it more fully ? Er, versions (or sessions) and undo provide some time travel, but of a rather destructive sort, what I have in mind is more like "have a peek at what it looked like a year ago and come back". My ideal would be something I would call "supertransactions", allowing daily or weekly records of "checkpoint states" to which one can come back; the "checkpoint states" themselves would be the result of the packing operation. ...this makes my mind drift to a more general question, which is not zope specific, but indeed relates to all kinds of collaborative constructions of data objects. Given the place in pure maths of what relates to the boundary between the commutative and the non-commutative, I am a bit surprised I've yet to see software give any first-rate citizen role, as a property, to the mutual commutativity of a pair of patches, in a way that reflects the wisdom of (those) mathematics. But then maybe this just reflects my current inculture, as a computer professional. On another hand, maybe I just replied to my first question ;-) Theory : "Zope only admits a singly linked arborescence because, under that model, it appears obvious that commutativity of patches can be expressed in terms of shared *spatial*areas* between states of web sites." Just kidding. Best regards, Boris Borcic -- "Modern Basic(s) carries on from his ancestor(s) the property of driving unsuspecting mindshare away from beauty"