Hehe, I'll try and keep this reply a bit shorter :)

@Steven: won't that prevent you from using the IPs in some kind of
range query? e.g. SELECT * FROM some_ips WHERE ip >= start_ip AND ip
<= end_ip  (maybe not a great example, but you get the idea)

My main reason for making primary keys unsigned by default is that
this is the convention for MySQL databases and in my opinion Rails
should follow this convention. A less important reason is that it
saves me extra work when creating new migrations as I get an unsigned
key out of the box!

I appreciate this would require developers to give some thought when
making the transition from pre-patch to post-patch versions of Rails,
however a similar scenario occurred when this change was committed:
http://github.com/rails/rails/commit/a37546517dad9f6d9a7de6e1dba4d960909d71e8
(for example what were once created as 4 byte integers could become 1,
2, 4 or 8 byte integers after this change).

I may be wrong but won't this old/new migration issue only arise in
situations where you're adding a new foreign key that references an
existing primary key, and even then only if you choose to use 'sexy'
syntax instead of add_column? And shouldn't you really do a quick
double check on a column type before adding an FK constraint, just in
case it's not the simple numeric key you were expecting?

Anyway, I think there are currently three options:

1. Change the default to unsigned for primary keys
Requires developers choose between updating their existing keys or
specifying :unsigned => false when creating new foreign keys that
reference old signed primary keys.

2. Add a :primary_key_unsigned => true|false setting to create_table
(default to false)
Requires developers manually specify when they want an unsigned key in
each new migration.

3. Add some kind of config setting (I'm not exactly sure where it'd
go) that determines the default for primary keys when using MySQL
Developers would then be able to choose the global default, this could
be combined with option 2 to allow the default to be overridden in
individual migrations. Seems like a few too many settings to me
though...


--

Rob Anderton
http://www.thewebfellas.com/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to