[Zope-dev] Detecting object deletions

[Jim Fulton]

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.