Subject: Re: [ aolserver-Bugs-588470 ] Memory leak when running Tcl scipts
Bugs item #588470, was opened at 2002-07-30 03:59
I was just looking at a bug email from Source Forge. This one is for AOLserver. Somehow I doubt that AOLserver has had 588469 previous bugs. I do see the desire to have nice small numbers for certain sequences, but first the vendor supplied sequence routines should always be used for that purpose, and they should probably be inside the __new pl routine that creates the object. However, then you are stuck trying to design new ways to return the new 'nice id' so that you can do things like redirect to the right place after the insert. All of the routine ways of doing things in OpenACS are now going to be ad-hoc, and for little or no advantage.
It is useless to consider moving the data in the design of a site. The problem of conserving external links will be the least significant problem. If you move to a different software, more than likely, it will not have the concept of a package either, so the package_id will present the same issue that the object_id presents.
What would be helpful would be an xml or other hierarchical language method of describing the data in your system. This language would aid in the creation of the datamodel, as well as the ability to dump/restore the data.
I think it would still be near impossible to move to another system when you consider the permissioning scheme the package will rely on.
Overall I don't think having big, not quite sequential numbers is a bad idea. It lends a little obfuscation to the workings of a site. It can make it more difficult to hack. For all the benefits you get from not having to deal with new sequences, and getting it wrong, not having to write extra code which is non-standard, I don't see why this is good. For application specific problems like this, maybe create an unique index on some fields in your primary table, I doubt the object_id foreign key is the only thing that makes the row unique. For the bug tracker maybe who submitted the bug and the date is enough. I doubt that one person would submit two bugs at the same time.
