[Zope-dev] Detecting object deletions

[Boris Borcic]

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"