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