Forum OpenACS Q&A: context_id, parent_id, package_id ...

Collapse
Posted by Don Baccus on
Actually the parent_id change, while talked about frequently over the past three years and part of the changes many of us have talked about making, may not've been TIP'd with Timo's package_id TIP, have to double-check. It may've been left out to keep the package_id changed at the bite-sized nibble level of effort so it could get done quickly.

Anyway, my vision of how these columns work, which I've held for a long time now ...

  1. context_id

    This should actually disappear as it's only used as something to hang a trigger onto for permissions, and it shouldn't be overloaded as a stand-in for the physical parent_id pointer. I won't go into details here other than to say that making it disappear would force programmers to use the API to change it, it would get rid of two columns in objects (security_inherit_p), and the API could forbid errors like trying to tell the system to not inherit permissions but to also inherit them from object FOO (we have to support this now due to the overloading by several packages of context_id as the physical parent_id). I think, but am not sure, that we might see improved performance (not much, just a little) during object creation.

  2. parent_id

    The physical parent of the object, the addition to acs_objects perhaps having been TIP'd already, perhaps not. Existing packages either overload context_id, package_id, or add a parent_id (content repository) so upgrade scripts would have to be written to take this into account. Fairly large job, worth doing IMO.

  3. package_id

    I've always looked at this as being primarily a convenience for the package author for those times when you want to find all the objects created by a package. For instance when you delete a package instance or when you uninstall a package systemwide. These scripts have historically been buggy and hard to write. Folks have overloaded package_id to make up for the lack of a physical parent field (i.e. notes) - historically their own private package_id but now carried into acs_objects - and, once a proper parent_id is added, this should be Strictly Forbidden :)

These are fairly complex changes but only due to (as is so often true) the need for upgrade scripts. But ... today you have to dissect a package to see if it's overloading context_id as the physical parent_id, or package_id, or providing its own parent_id, or confusing itself by doing some mix of two or even all three of the above. We'd be rid of that at last.