Forum OpenACS Q&A: Re: RFC: Avoid exposing object_ids in permanent URLs

Collapse
Posted by Andrew Piskorski on
So, what is the conclusion here? The "just use the object_id" camp seems to have mustered the stronger arguments, but then, I'm in that camp... Is there sufficient consensus to make an OpenACS policy on this?

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:

select nvl(max(patch_number),0) +1
into   v_patch_number
from   bt_patches
where  project_id = new.project_id;
The code neither locks the bt_patches table 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.