I think the package_id to define where an object belongs almost works.

I like the content repository model of parent_id better.

This builds an explicit object hierarchy that is often, but not always reflected in acs_objects.context_id.

I would love to explore the possibilites of setting up an object hierarchy for all objects similar to the cr_item.item_id, cr_item.parent_id model. Unfortunately it seems like a huge amount of work and package_id would help with some queries where we want to know which package created an object.

I think in the long run, storing items in a folder tied to a site-node ends up being very useful for partitioning objects.

I guess this is all something to think about for the future, but doesn't decide this TIP.

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.

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.

The way I see it, we need 3 things:

1. An inexpensive way to get a URL for an object. The /o/ trick is the best solution to this I've seen so far.

2. Where in a hierarchy of object this belongs. For a forums message, it would be the path to the forums package, but also include the forum. For a logger entry, it would include the logger package and the logger project.

In general, I want to move towards a data-centric design rather than a package-centric design, so objects don't belong to packages, but to any container - a folder, another item, etc.

3. If we want to present the item, we also need information that pertains to the particular object type, to get the name of the object and other relevant pieces of information. These other pieces of information may even depend on the object type.

(Branimir told me a trick, where a "presentation" column was stored in a central place, such as acs_objects. This column contains whatever the object type decides to store there, to use when presenting objects of this type, without hitting the type-specific tables.)

Thus, we need to talk about how this fits with the road-map.

For 5.1, if it solves an important immediate problem, I'd be okay with this solution,

But for 5.2, I'll want to revisit and think about a proper solution that will work for a data-centric approach. We should discuss that as soon as we've pushed 5.1 out.

/Lars

I didn't present this as a TIP yet since i thought agreeing on something as basic as pretty_name, package_id and id->url resolution would be easier and more needed at first.

When will this be added to head?  I just made the contrib/portals package subsite-aware and would love to use the acs_object package_id rather than the one I just added to the portals table!

Also we need a default package for those objects for which no package_id is specified ... should we make the acs-kernel package a "magic object" to be used as default?  I'm thinking in terms of upgrade scripts for packages that currently aren't "subsite-aware" and don't currently carry a package_id in its type-specific tables.

Interesting to see the "data-centric" argument and the notion of a proper object hierarchy using a parent_id separate from context_id arise again.  That's something I've wanted (pulling it from content-item ...) for a long time.  Actually I'd like to pull context_id from the object altogether and have packages manipulate the context relationships explicitly since only the denormalized map is used (the current system requires making a new copy of the object tuple in PG as well as the map tuples every time you change the context relationships which is relatively inefficient).

But all such changes require considerable effort be put into upgrade scripts so moving forward incrementally is a good idea.

Should we put an "on delete cascade" referential action on the package_id column in acs_objects?  This would be a step in the direction of simplifying the dropping of a package instance (and this further leads to an argument that having package_id around might be a good idea even if we move towards a more data-centric POV...)