The need to call a PL/SQL function to get the live revision is due to a religous belief that a line of code that reads
content_item.get_live_revision()
is more "abstract" than one that reads
cr_items.live_revision
an argument I don't make :)
package_id ... not sure one way or another. I would certainly agree it can be useful for content items. I know so because I added it to content items when working on the Greenpeace site, and it was very very useful! We used it when grabbing all content generated by a particular package, i.e. "news for the dutch greenpeace site".
Package instances should create their own root folder and in theory this can be used to find all content generated by the package. But in our case at Greenpeace we inherited some bad code that didn't bother to correctly generate root folders for each instance, just one shared by all instances...
Can you provide some specific examples where it has been useful? There's quite a bit of sentiment to make "context_id" be a true "parent_id" (I know this goes against the original design but in practice aD itself released a bunch of code that depends on it, bboard for instance). If we do that finding all objects generated by a package becomes a matter of casting the right CONNECT BY or tree sortkey query (depending on which RDBMS you're using) and these aren't terribly expensive. More expensive than querying for the package_id but then again more general because you can query for the subtree underneath any object, not just a package ...
