In any case you also have to deal with the circular reference acs_object --> package --> acs_object.
I just ran into a variant this on the Oracle HEAD. In oracle, a foreign key constraint from acs_objects.package_id is getting added in apm-create.sql, and this was breaking the install. It looks like the PG version simply doesn't define the constraint. It looks like we can keep the constraint by rearranging the code in apm_package.new to first insert into apm_packages, then update acs_objects.package_id. Not sure who is actively looking at this.
One of the main reasoning for this TIP is that it's needed (as i explicitly mentionend in the TIP) for search and categories since these are packages dealing with objects of unknown origin and there has to be a way of showing a list of arbitrary objects to the user (thus the need for an object-name at a central place) together with links to the objects (thus the need for package_id and a url derived from the object_id).
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.
It's late to be kibbitzing on this, but while I agree about the need to cheaply get an object's name (and, for that matter, the object creator's name), there is a simple trick for getting the object's URL. Namely, you defer those calculations and put them on another page. So every object links to "/one-object?object_id=123456", and then you have one-object.tcl do the expensive lookups which would not be feasible on a page that returns lots of objects of different types. I think this is what Lars is talking about when he refers to the "/o/ trick".
