R: [Zope] Discussion: Best practice site struture (LONG)

[Max M]

Luca Olivetti wrote:

> Max M wrote:
>
>> Well in fact it is VERY easy to do in the ZODB. My mxmRelations 
>> product does exactly this.
>
>
> I'm using it right now (with a modification to add absolute_url to the 
> attributes returned by smartlist) and I find it very useful, thank 
> you, but still I think it is a hack: you do the relational magic by 
> storing the path of the object. Move an object (copy & paste or 
> rename) and the relation is gone (not a big deal, btw).


Yes that is true. In my ver. 0.3 I have a few simple hooks (2 methods) 
that an object can call to keep relations even when they are moved. The 
product could be simpler if every object in Zope had a unique object Id. 
Then it could happen automatically.

> Export a site using relations and import it in a different subtree and 
> the relations are gone (this *is* a big deal: you can't safely use 
> export/import). Delete an object, create another one with the same id 
> and see the old relation pointing to it. 


There is no easy solution to this. Currently the only "global object 
identifier" (goid) in zope is the path to the object. It's is sort of 
like the key in a rdbm's. When you move a bunch of objects to another 
location you change their "key". If you did this in a rdbm's you would 
get the same problem.

Adding a true goid to Zope would not even solve this because the goids 
might allready be in use in the new zope instance you are copying to.

What you probably should do is write a script that get's the links from 
one relations instance and then recreates them in the new one.

> The management interface should show dangling links instead of just 
> hiding them. 


Not in the current implementation. The product currently deletes 
relations that no longer has valid objects. I did this so that you 
cannot remove an object with one meta_type and add one with another 
meta_type but the same id. This, I guess could seriously screw up the app.

A possibility is to add the metatype to the relations and then keep the 
dead links instead ... that would also make a few other interresting 
oportunities possible and is a pretty simple change. But it does have 
the effect of filling up the database with dead relations And the more 
there are of them, the bigger the chance of a new object getting an 
unexpected relation.

It is also possible to make a checkbox so that it's optional, but I 
think it is dangerous.

> And if you want referential integrity you still have to code it by 
> hand in each object (i.e. by implementing manage_beforeDelete).


This will probably never change. What should happen when an object is 
deleted is application and object specific and cannot be more 
generalized than to a hook.

> Even with these shortcomings it *is* an useful product, but I hope 
> that relations in core zope are implemented with the set of features 
> that a relational database gives you.


Yes it could be better. But I think it's about as good as the current 
Zope allows. We need the ExplicitObjectReference goddarn it.

regards Max M