Hi,
I was only able to read the thread now, I hope what I post is relevant. Based from what I see we can use CR for this situation rather than adding to acs_objects.
cr_folders already contain package_id column. This can be used rather than putting a package_id on cr_items. Logically we would want to group items in a container like cr_folders. So a package can get its items that has a cr_items.parent_id = cr_folders.folder_id and cr_folder.package_id = :my_package_id. ETP already functions this way.
Based from experience content_item__get_path is very expensive, although content_item__get_virtual_path is a little cheaper. What I did to generate the url was actually to query some extra rows. This rows are the ancestor of the cr_item I am interested in. Then on tcl level I generate the url. It was a lot faster. A few more extra rows on the result set and some tcl manipulation. Rather than using pl/sql to get the url.
As far as live or latest content is concerned. Using the pl/sql api is a lot slower rather than query the cr_items.live_revision or cr_items.latest_revision directly. But the pl/sql is useful on some situation, but my rule of the thumb is to query if possible the live/latest revision.
Using tcl api to access CR is definitely easier at the expense of less flexibility. I have already made a lot of the tcl procs to access CR, after using them I would like to change them a bit. To make things better.
I hope its relevant.
