I didn't participate in this discussion because a) I was getting ready to go to Guatemala and b) I'd expressed my support for this many times in the past.
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...)
