Rails - Apr 2007 - How can I create a column of bigint sql type in migration?

Hi all,

I want to use bigint sql type for a model''s id. How can I do this in
migration? Should I just use the integer ruby type?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

i would think that the standard INT column type would be enough, as,
even when signed, allows for values over 2 billion (over 4 billion
unsigned) where a BIGINT would allow for over 9 quintillion
(9,000,000,000,000,000,000).

so if you really do need a BIGINT data type, there is no way to do it
via standard migration functionality.

you can issue an alter table command and change the column type however.

self.up
  ...
  execute("ALTER TABLE things CHANGE column_name column_name BIGINT")
end

On 4/9/07, allen <allenmacyoung-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Hi all,
>
> I want to use bigint sql type for a model''s id. How can I do this
in
> migration? Should I just use the integer ruby type?
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Not to call you out Chris but have you ever tried

class CreateThings < ActiveRecord::Migration
  def self.up
    create_table :things do |t|
      t.column :my_big_int, :bigint
      t.column :my_medium_text, :mediumtext
      # You can even specify limits!
      t.column :my_char_64, :"char(64)"
    end
  end

  def self.down
    drop_table :things
  end
end

in your migrations. I think you''d be pleasantly surprised by the
results.
Yes, it''s database specific. Yes, it doesn''t have
DDH''s imprimatur. But
sometimes it pays to be agile. :) The only downside I saw was that the
schema.rb file doesn''t correctly reflect the actual database. What
MySQL
truly recognizes as CHAR(64) is label in the schema as :string, :limit =>
64, which _is_ database agnostic but not exactly true to the DB. What this
would entail in actual practice? I dunno. I''ve never used the
schema.rb[that I know of] so it''s possible that there are no drawbacks
but I thought
in the interest of full disclosure that I''d let y''all know.

On 4/9/07, Chris Hall
<christopher.k.hall-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

if you really do need a BIGINT data type, there is no way to do
it
> via standard migration functionality.
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

you''re right, i''ve never used :bigint, as I was going by the
documentation at

http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/TableDefinition.html#M000762

which states that only the following

:primary_key, :string, :text, :integer, :float, :decimal, :datetime,
:timestamp, :time, :date, :binary, :boolean

are allowed parameters when specifying column type.

On 4/9/07, Russell Norris
<rsl-ftMzyaTR+bHNyFkoKTPOtdi2O/JbrIOy@public.gmane.org>
wrote:
> Not to call you out Chris but have you ever tried
>
> class CreateThings < ActiveRecord::Migration
>   def self.up
>     create_table :things do |t|
>       t.column :my_big_int, :bigint
>       t.column :my_medium_text, :mediumtext
>       # You can even specify limits!
>       t.column :my_char_64, :"char(64)"
>     end
>   end
>
>   def self.down
>     drop_table :things
>   end
> end
>
> in your migrations. I think you''d be pleasantly surprised by the
results.
> Yes, it''s database specific. Yes, it doesn''t have
DDH''s imprimatur. But
> sometimes it pays to be agile. :) The only downside I saw was that the
> schema.rb file doesn''t correctly reflect the actual database. What
MySQL
> truly recognizes as CHAR(64) is label in the schema as :string, :limit
=>
> 64, which _is_ database agnostic but not exactly true to the DB. What this
> would entail in actual practice? I dunno. I''ve never used the
schema.rb
> [that I know of] so it''s possible that there are no drawbacks but
I thought
> in the interest of full disclosure that I''d let y''all
know.
>
> On 4/9/07, Chris Hall
<christopher.k.hall-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > if you really do need a BIGINT data type, there is no way to do it
> > via standard migration functionality.
> >
>
>
>  >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I think that the API is aimed at being as db-agnostic as you can. Which I
completely _do_ agree with. I was just trying to share the wealth with my
twocents. Sometimes you have situations that don''t have to be
db-agnostic
and if you''re aware of the pros and cons you should go where agile
takes
you.

RSL

On 4/9/07, Chris Hall
<christopher.k.hall-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> you''re right, i''ve never used :bigint, as I was going by
the documentation
> at
>
>
>
http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/TableDefinition.html#M000762
>
> which states that only the following
>
> :primary_key, :string, :text, :integer, :float, :decimal, :datetime,
> :timestamp, :time, :date, :binary, :boolean
>
> are allowed parameters when specifying column type.
>
> On 4/9/07, Russell Norris
<rsl-ftMzyaTR+bHNyFkoKTPOtdi2O/JbrIOy@public.gmane.org> wrote:
> > Not to call you out Chris but have you ever tried
> >
> > class CreateThings < ActiveRecord::Migration
> >   def self.up
> >     create_table :things do |t|
> >       t.column :my_big_int, :bigint
> >       t.column :my_medium_text, :mediumtext
> >       # You can even specify limits!
> >       t.column :my_char_64, :"char(64)"
> >     end
> >   end
> >
> >   def self.down
> >     drop_table :things
> >   end
> > end
> >
> > in your migrations. I think you''d be pleasantly surprised by
the
> results.
> > Yes, it''s database specific. Yes, it doesn''t have
DDH''s imprimatur. But
> > sometimes it pays to be agile. :) The only downside I saw was that the
> > schema.rb file doesn''t correctly reflect the actual database.
What MySQL
> > truly recognizes as CHAR(64) is label in the schema as :string, :limit
> =>
> > 64, which _is_ database agnostic but not exactly true to the DB. What
> this
> > would entail in actual practice? I dunno. I''ve never used the
schema.rb
> > [that I know of] so it''s possible that there are no drawbacks
but I
> thought
> > in the interest of full disclosure that I''d let
y''all know.
> >
> > On 4/9/07, Chris Hall
<christopher.k.hall-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > > if you really do need a BIGINT data type, there is no way to do
it
> > > via standard migration functionality.
> > >
> >
> >
> >  >
> >
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I agree whole-heartedly.  There are quite a bit of hidden/unknown
features that can definitely be taken advantage of if you know about
them and the pros outweigh the cons.

On 4/9/07, Russell Norris
<rsl-ftMzyaTR+bHNyFkoKTPOtdi2O/JbrIOy@public.gmane.org>
wrote:
> I think that the API is aimed at being as db-agnostic as you can. Which I
> completely _do_ agree with. I was just trying to share the wealth with my
> twocents. Sometimes you have situations that don''t have to be
db-agnostic
> and if you''re aware of the pros and cons you should go where agile
takes
> you.
>
> RSL
>
>
> On 4/9/07, Chris Hall
<christopher.k.hall-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> >
> > you''re right, i''ve never used :bigint, as I was
going by the documentation
> at
> >
> >
>
http://api.rubyonrails.org/classes/ActiveRecord/ConnectionAdapters/TableDefinition.html#M000762
> >
> > which states that only the following
> >
> > :primary_key, :string, :text, :integer, :float, :decimal, :datetime,
> > :timestamp, :time, :date, :binary, :boolean
> >
> > are allowed parameters when specifying column type.
> >
> > On 4/9/07, Russell Norris
<rsl-ftMzyaTR+bHNyFkoKTPOtdi2O/JbrIOy@public.gmane.org> wrote:
> > > Not to call you out Chris but have you ever tried
> > >
> > > class CreateThings < ActiveRecord::Migration
> > >   def self.up
> > >     create_table :things do |t|
> > >       t.column :my_big_int, :bigint
> > >       t.column :my_medium_text, :mediumtext
> > >       # You can even specify limits!
> > >       t.column :my_char_64, :"char(64)"
> > >     end
> > >   end
> > >
> > >   def self.down
> > >     drop_table :things
> > >   end
> > > end
> > >
> > > in your migrations. I think you''d be pleasantly
surprised by the
> results.
> > > Yes, it''s database specific. Yes, it doesn''t
have DDH''s imprimatur. But
> > > sometimes it pays to be agile. :) The only downside I saw was
that the
> > > schema.rb file doesn''t correctly reflect the actual
database. What MySQL
> > > truly recognizes as CHAR(64) is label in the schema as :string,
:limit
> =>
> > > 64, which _is_ database agnostic but not exactly true to the DB.
What
> this
> > > would entail in actual practice? I dunno. I''ve never
used the schema.rb
> > > [that I know of] so it''s possible that there are no
drawbacks but I
> thought
> > > in the interest of full disclosure that I''d let
y''all know.
> > >
> > > On 4/9/07, Chris Hall <
christopher.k.hall-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > >
> > > > if you really do need a BIGINT data type, there is no way to
do it
> > > > via standard migration functionality.
> > > >
> > >
> > >
> > >  >
> > >
> >
> >
> >
> >
>
>
>  >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

allen wrote:
> Hi all,
> 
> I want to use bigint sql type for a model''s id. How can I do this
in
> migration? Should I just use the integer ruby type?
Just use
  t.integer :foo, :limit => 8


-- 
Posted via http://www.ruby-forum.com/.

>> I want to use bigint sql type for a model''s id. How can I do
this in
>> migration? Should I just use the integer ruby type?
> 
> Just use
>   t.integer :foo, :limit => 8
I''m pretty sure that doesn''t do what you think it does. It
creates a an
int(8) in mysql (as opposed to the default which is int(11)) but this 
does not affect the size of the number that can be stored in the field. 
An int field in mysql is 32 bits long regardless of the :limit you set 
(that''s only the ''display'' length).

If you want to store numbers greater than 2147482624 you hvae to use 
bigint.

steve

-- 
Posted via http://www.ruby-forum.com/.