Forum OpenACS Q&A: Re: RFC: Avoid exposing object_ids in permanent URLs
One more argument:
Correct me if I'm wrong, but the latest code in Lars's new Bug Tracker
package still has a race condition when creating these pretty
"expose it in the URL" ids in
bt_patch.new. That's both
on the head and on the 4.6 branch, both Postgres and Oracle:
The code neither locks theselect nvl(max(patch_number),0) +1 into v_patch_number from bt_patches where project_id = new.project_id;
bt_patchestable nor does anything else fancy (like pre-allocating rows in the style of some room reservation systems), so as far as I can see it's just plain wrong.
I think we can all agree that Lars is one of our best and most skilled developers, yes? So if he got it wrong, what does that say about how likely other developers are to get it wrong?
Therefore, I suggest that if the, "No, we don't want to expose the object_id in URLs, we want something else" camp really wants their way, that a necessary (but not necessarily sufficient) requirement is that is someone first design and implement a general, scaleable, and correct solution that can be used by any package to map object_ids to some or one "pretty" id representation.