On K, 2008-06-04 at 06:25 -0700, rob-twf wrote: > As a practical example: I originally started work on this because I > wanted to store IPv4 addresses in my database, and to do that I really > needed an unsigned 32 bit integer. > > Hope this helps...
Yes, I agree that for IPv4 it is indeed useful. But I do have a few more questions. 1. If unsigned was made default and a project that was built before this started using the newer migration code that would mean that part of their database uses unsigned and part uses signed integers. 2. Does mysql support changing the type of a column (including a primary key column) from signed to unsigned? Would rails' change_column be able to do it? 3. I think mysql does not support FK's between different integer types, so wouldn't making unsigned the default cause problems for all new FK fields (and their constraints) that refer to existing tables (with signed int primary keys)? Apart from the possibility of storing IPv4 addresses the usefulness of this seems quite limited, most applications probably do not have tables that touch the limit of 32bit signed integers and even if they did a two-fold increase in the number of keys would not be a good long-term solution. So basically I'm concerned about the fact that making this the default seems to not give great benefit yet unless I'm wrong about the above things could cause issues if done so for an existing project. So perhaps the default should be configurable and at least for older applications should not be changed? Thank you, -- Tarmo Tänav <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
