Not if you convert your ip to the compressed signed integer format first.
I think your option 3 below is the best choice. On 4-Jun-08, at 3:46 PM, rob-twf wrote: > > 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 -~----------~----~----~----~------~----~------~--~---
