Boris Borcic wrote:
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 ?
No.
What is the morale of this constraint ?
There is no such constraint. OTOH export/import (and therefore copy and paste) can get a bit strange if you export an object that references an object that lives in an unrelated part of the object hierarchy. The referenced object gets copied too, so the reference to the original referenced object is essentially broken. This is currently a problem with ZClass instances. Currently, when a ZClass instance is copied, it's class gets copied too, which is not a good thing.
What about circulat references ?
What about them? ;) Circular references do not cause memory leaks in persistent objects: - When the cache manager turns an inactive object into a "Ghost", links to other objects are broken, this eliminating circularreferences. - Packing, which accomplishes garbage collection in the database follows references from the root object and does not rely on reference counting.
What will break if I use multiply linked objects ?
Nothing, although you'll want to ponder the semantics of copy/paste (export/import).
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 ?
It depends on how you use ids. Certainly, an object's absolute_url method will give incorrect results if it's id is incorrect.
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 ?
Ah, I see where you are going with this. I think this should take care of it. Clearly, assumptions about how an object is used (is it managed by multiple containers) affects it's design. The places in Zope where objects are currently multiply accessed tend to be under the hood and unaffected by things like url-traversal issues.
How much of the problem is simply to make very sure the user can't make circular references ?
Well, the current user interface doesn't let them make circular references. There *is* something inherently (and very subtley) evil about circular references. Multiple references is something else. This is really the issue here and has to do with the way objects are addressed.
Why don't objects fully acquire their id ? Or did I miss it ?
Where would they acquire it from. The answer *may* be some kind of symbolic linking facility.
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.
Right. If you want complete time travel, don't pack.
Is there any plan to support it more fully ?
Yes, although they are pretty nebulous at this point.
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".
Right. You can do this in a brute force fashion now by setting up a site that uses the database in a read-only mode. This is alot of work though.
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.
I'm not sure why this would have anything to do with packing. You have all of the information needed sitting around in the database. There's just no good framework at higher levels to make it accessible. If you want to pursue some experiments in this area, I'd be happy to advise.
...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.
You lost me. You'll have to explain this to me some time over a beer. ;)
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.
Whew. Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.