Non-integer keys have been very well supported, up to at least 2.0.2.
I wrote a plugin that uses UUID primary keys and have only had one
problem in the past two years (and Frederick fixed it quickly). And
most plugin providers also support non-integer primary keys (two years
ago, for example the developer of acts_as_ferret retrofitted string
keys in short order).
And the support is not just a situation where you can hack Rails code
to do it. It's actually pretty easy... Rails provides methods to
define the primary key name and in the remainder of the code no
assumptions are made as to the type value used for the PK. My plugin
is less than 60 lines of code but the reality is that you could write
your own in ten lines of code.
There are two caveats that I don't expect will be addressed by Rails:
migrations with deviant primary keys and Foxy Fixtures with deviant
primary keys. Although in both cases my plugin addresses the problems
nicely -but with monkey patches. In fact, in the case of Foxy
Fixtures, I've restored about 90% of the Foxy Functionality when using
UUID primary keys.
Given the very high level of support for string keys already in place,
it would be a shame to break it now.
I won't get into the religion of meaningful keys, but know that many
programmers prefer to have their PKs correlate to "real world"
attributes that are not integers. This is particularly true in legacy
My plugin is available here for checkout:
and here for browsing so you can see just how simple it is:
PS - I will go so far as to say that in an ideal world, Rails would
offer support for UUID primary keys out of the box. It is dead simple
and provides many advantages in distributed applications -Adobe Air
and other apps with standalone clients come are good examples. And
UUID are very analagous to the auto-incrementing integers Rails
already uses: they can be generated at the database and they are
guaranteed to be unique.