Forum OpenACS Improvement Proposals (TIPs): Re: TIP #42 (Proposal) Adding package_id to acs_objects
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.
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.
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.