Rails - Jun 2006 - ActiveRecord Migrations, without autonumbered PK''s

I love using ActiveRecord Migrations to build tables.

Sometimes, I don''t want to use autogenerated PK''s - I want to
set them
automatically (why?  I''m importing read only data from a large list of 
medications, and want to use the PK''s assigned by the medication 
research company...).  Is there anyway to do this using Migrations?  I 
know that I don''t need to set a PK, but I want to set a PK - just leave
it manual.


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

create_table :foo, :id => false do |t|
end

I think you''d be better off creating a unique
ID on the research company''s data, in addition
to Rail''s ID, but if you want the extra pain,
go for it.

--  
-- Tom Mornini

On Jun 30, 2006, at 6:31 AM, Robert James wrote:
> I love using ActiveRecord Migrations to build tables.
>
> Sometimes, I don''t want to use autogenerated PK''s - I
want to set them
> automatically (why?  I''m importing read only data from a large
list of
> medications, and want to use the PK''s assigned by the medication
> research company...).  Is there anyway to do this using Migrations?  I
> know that I don''t need to set a PK, but I want to set a PK - just
> leave
> it manual.
>
>
> -- 
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails

On 6/30/06, Tom Mornini <tmornini@infomania.com>
wrote:
> create_table :foo, :id => false do |t|
> end
>
> I think you''d be better off creating a unique
> ID on the research company''s data, in addition
> to Rail''s ID, but if you want the extra pain,
> go for it.
+1 on Tom''s comment.  External Primary Keys should be a separate
column in your table.  It''s not the *only* way to do it, but
it''s by
far the least painful.  Everything works much more seamlessly when you
have your autonumber "id" field and a separate
"external_key" (or
whatever) field.  It''s just as easy to do the import and much less
painful to do anything else.


-Curtis

Tom Mornini wrote:
> create_table :foo, :id => false do |t|
> end
I *do* want a PK, just not autonumber.
Using the method primary_key() makes it autonumber.
> 
> I think you''d be better off creating a unique
> ID on the research company''s data, in addition
> to Rail''s ID, but if you want the extra pain,
> go for it.
> 
I certainly agree that ActiveRecord is happiest this way.  Let me 
describe a bit more the situation, and maybe you''ll see why I want to
do
differently, nonetheless:

The research consists of huge numbers of files, with huge numbers of 
records, referencing eachother through integer FK''s, in text delimited 
formats.

Using random PK''s makes loading the references a nightmare.  The load 
procedure needs to do all the work manually.  If you make a mistake, 
it''s very hard to sort out what happened.  Adding new tables (purchased
later) is very hard.

The data is read only under normal operations - all we do is load it - 
so I''d rather make the load easy.

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

Robert James <srobertjames@...> writes:
> 
> I love using ActiveRecord Migrations to build tables.
> 
> Sometimes, I don''t want to use autogenerated PK''s - I
want to set them
> automatically (why?  I''m importing read only data from a large
list of
> medications, and want to use the PK''s assigned by the medication 
> research company...).  Is there anyway to do this using Migrations?  I 
> know that I don''t need to set a PK, but I want to set a PK - just
leave
> it manual.
It''s a little clunky, but you can do this:

--
create_table :my_table, :primary_key => :guid do |t|
end   
change_column :my_table, :guid, :string, :limit => 32
--

The first step creates an autonumber column called guid and the second step
changes the type of that field.

hth,
-damon
http://damonclinkscales.com/