One of the main advantages would be that it allows you to optimise your database structure, for example, if you want to store a value up to 4294967295 in an integer field you can either do it with a signed bigint (which needs 8 bytes of storage) or in an unsigned integer (which only needs 4 bytes). While a 4 byte saving may not sound huge, it can quickly add up and can also have a knock-on effect for indices on those fields.
Of course this applies to other integer types in MySQL too: for example a 2 byte signed smallint vs a 1 byte unsigned tinyint to store values up to 255, etc. Rails will use a Bignum class for values above 2147483647, it'll continue to use Fixnum for smaller unsigned attributes. 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... -- Rob Anderton http://www.thewebfellas.com/ On Jun 4, 11:14 am, Tarmo Tänav <[EMAIL PROTECTED]> wrote: > On K, 2008-06-04 at 00:52 -0700, rob-twf wrote: > > > Hi all, > > > I posted this patch the other day, now it's time to drum up some > > support for it :D > >http://rails.lighthouseapp.com/projects/8994/tickets/300-unsigned-int... > > > To summarise, it does the following: > > > * changes the primary key data type for the MySQL adapter to be > > "int(11) unsigned" > > Hi, > > Why do you need unsigned integers and what happens if the values go > outside the range of signed integers, will rails fall back to > BigDecimal? > > -- > 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 -~----------~----~----~----~------~----~------~--~---
