Forum OpenACS Improvement Proposals (TIPs): Re: TIP #42 (Proposal) Adding package_id to acs_objects

Posted by Timo Hentschel on
One of the main reasoning for this TIP is that it's needed (as i explicitly mentionend in the TIP) for search and categories since these are packages dealing with objects of unknown origin and there has to be a way of showing a list of arbitrary objects to the user (thus the need for an object-name at a central place) together with links to the objects (thus the need for package_id and a url derived from the object_id).

From my point of view all that a user wants after he found the objects of his desire through search or categories is that he wants to see the object. Personally i don't want to have the very same object listed a couple of times if there's more than one package that could deal with this particular object - i would want to see each object only once in the result list and if that means we show only the creator package and not also the editor packages then this would be perfectly fine with me. That is why i don't really see any need for a mapping table. But if the majority here sees it otherwise with a good reason (not convinced yet) to add yet another table to join with - then so be it.

Posted by Dirk Gomez on
The thread remained unanswered because nobody had a compelling example for or against a mapping table (and because I had lost interest in this matter)

I am siding with Timo because for the problems that are supposed to be solved I cannot see where a one-to-many relationship is necessary: If OpenACS were more data-centric I could imagine a whole lot of good uses for multiple package_ids. We are currently application-centric and I don't see that this will change too quickly, so a mapping table would only complexify things. And complexifying code for a future promise often doesn't work.

Posted by Jeff Davis on
First of all I vote yes.

On Tom's objection I think we already have a mapping table in the form of acs_rels where we would could do many to many maps if needed but for something we think has value to provide for most objects we would like not to add the overhead of creating an acs_rel object just to map to the owning package. Also even if we used a many to many table we generally would want a single "owning package". To enforce that constraint in the mapping table with schema like (package_id, obj_id, relation) would be expensive and less desirable than having a single field in the acs_object table.

Furthermore we have had acs_rels for some time and it is barely used so I don't see any compelling argument that we need add more complexity to support something we have not used to date.

Enough packages have package_id in their object specific store that I think it's sensible to denormalize it and make an effort to ensure that all packages maintain it.