Bug 225221 - a primary key for longdescs
zak at sxip.com
Fri Oct 15 17:07:21 UTC 2004
I have been lurking, watching to see what happens with the Sxip stuff.
However, since I used to work for MySQL, I could not resist this
On Oct 14, 2004, at 15:37, David Miller wrote:
> Christopher Hicks wrote:
>> On Mon, 11 Oct 2004, Joel Peshkin wrote:
>>> Also, nobody is obstructing that bug, but nobody seems to have taken
>>> on the task of making the conversion code work properly. For
>>> existing databases, it is probably necessary to first assign
>>> integers to the new field in the correct order, then identify the
>>> new field as a primary key.
>> That won't work! How can you assign integers to something you can't
>> uniquely refer to? The simplest and most painless way to get past
>> the chicken and egg problem is by having MySQL do it (as my patches
>> have done) you end up with a primary key already filled out for you.
>> It seems so simple yet its taken so long and folks still don't get
>> it. So I gripe.
> You missed the "in the correct order" part. MySQL will happily assign
> them for you, but there's no guarantee they'll wind up in the order
> you expect them. On the other hand, if there is such a guarantee,
> point it out to me in the MySQL docs and I'll change my mind. :)
MySQL, in most common use cases, will generate a sequential set of
integers. As rows are deleted, the corresponding integers will not be
re-used. The exceptions to this are multi-column primary keys with
auto_increment fields and some versions of MySQL > 3 years old.
Still, why rely on a feature that is only supported by one database? It
seems better to be more independent. <shrug>
More information about the developers