I am building a rails 3 application with a products model. I've been trying to find a way to use the product id number as the identifier rather that using the models default ID.
I initially tried to use the to_param method, however I could not get it to work correctly.
I then rebuilt my database using the products ID number instead of the primary key as so:
class CreateProducts < ActiveRecord::Migration
def change
create_table :products, :id => false, :primary_key => :prod_id do |t|
t.string "prod_id"
t.string "upc"
t.text "title"
t.text "description"
t.timestamps
end
end
end
And changed my code to find/create using the prod_id. This seems to be working great, however I was hoping to find out a little more about any consequences this may have, and what the disadvantages of not using a primary key maybe.
I was hoping to find out a little more about any consequences this may have, and what the disadvantages of not using a primary key maybe.
You are using a primary key - it's prod_id. You're just not using a default setting auto-incrementing key (presumably though, prod_id is auto-incrementing and uniquely constrained? So you might as well have just left it as id for convention's sake...).
If you tell your model that it's using a different primary key, you shouldn't need to do any other configuration (or specification in associations - the prod_id will be picked up by reflection).
class Product < ActiveRecord::Base
set_primary_key :prod_id
...
end
(different versions of Rails have twiddled with the methods for doing this... check the API for whatever you're using)
There's no magic to choosing to use a non-default primary key - you just need some field that uniquely identifies each row. What it's called, and what its data-type is is practically irrelevant - if you really want to, you can configure your app to use GUID strings as IDs :-)
Related
I was storing a log of activities using an ActiveRecord model and it seems that one can dispose of the primary key:
class NetLog < ApplicationRecord
def self.primary_key
nil
end
I can create records, query for them, and loop across results. Surely I will unable to update, but it is a log, no updates expected. So it seems to work for my purposes. Now I wonder, am I using a documented option?
EDIT: Ah, I see, the problem was that also my ApplicationRecord (legacy) likes to set a primary_key, and then it seems to override the setting in the migration.
So perhaps a cleaner question is: How does the setting of self.primary_key interacts with the settings in db/schema.rb? My guess now is that if no primary_key is defined, schema.rb is examined to set the primary_key, but that if a primary_key getter is defined, schema.rb "id: false" is ignored
This is one of the ways, but why have a id column in the first place if you want the value to be nil? You can create a table without primary key using Rails migrations
create_table :net_logs, id: false do |t|
t.string ...
end
Hope that helps!
I have a table called Contracts. Its current default primary key is the :id field that Rails automatically generates, which is an integer. I want to have a field called contractId that is a string type and use it as a primary key instead. What I want to know is:
Is this a best practice? Are there any potential issues with doing this?
How I would go about it
Ruby on Rails (RoR) likes to emphasise the concept of convention over configuration. Therefore, it seeks to minimialise the amount of configuration.
So if you want contractId that is a string type then you can add one extra field in your table and use it wherever you want and let the Rails use id as primarykey.
Change PrimaryKey
Generate a new migration file name it "ChangePrimaryKey" (You can give any name).
class ChangePrimaryKey < ActiveRecord::Migration
def up
remove_column :table, :id # remove existing primary key
rename_column :table, :udid, :id # rename existing UDID column
execute "ALTER TABLE table ADD PRIMARY KEY (id);"
end
def down
# Remove the UDID primary key. Note this would differ based on your database
execute "ALTER TABLE table DROP CONSTRAINT table_pkey;"
rename_column :table, :id, :udid
add_column :table, :id, :primary_key
end
end
If you are creating a new table, your migration might look like this:
class AddTableWithDifferentPrimaryKey < ActiveRecord:Migration
def change
create_table :table, id: false do |t|
t.string :id, null: false
# other columns
t.timestamps
execute "ALTER TABLE table ADD PRIMARY KEY (id);"
end
end
end
Notice the id: false options you pass into the table — this asks Rails not to create a primary key column on your behalf.
Changes to Model
In the model, it is essential that you add the following line in order for
Rails to programmatically find the column you intend to use as your primary key.
class Table < ActiveRecord::Base
self.primary_key = :id
# rest of span
end
I hope you can do rest of the things.
Don't change default id if you want to see Rails real Magics :)
As you may know, Rails supports changing the primary id column out of the box:
class Contract < ActiveRecord::Base
self.primary_key = "contractId"
end
Please note that even if the contractId column has a unique index, an index on a string column will always be a bit slower than an index in an integer column.
Furthermore, this is not the Rails way and might confuse other developers that work with this application. Especially building associations or routes are error-prone when your table has a non-standard primary key. IMHO that is a good reason to avoid using this technic as long as possible.
Want to do rails migration but i want the column name to be something like external_id but I don't want to any model with external . i think rails by default , whenever sees _id as suffix it looks for foreign key association and if it doesn't exist migration is canceled.
what's the solution for that. I have
def self.up
create_table :external_mappings do |t|
t.string :external_name
t.integer :external_id
t.timestamps
end
end
Thanks for your help
when i make it t.integer :externalId migration works. that make me think external_id is looking for foreiegn key reference, is there any way we can suppress foriegn key reference. I am using rails 2.3.5
You can give to any column a _id name and reference foreign keys without the _id also, so feel free to continue. It is just a convention on which Rails relies to target the model-name_id, but with no trouble it can be defined differently.
No, rails does not cancel any migration due non existent model.
I wonder if the original poster created the new model using scaffolding and the "references" type. If that is the case, the migration would have failed during it's attempt to creating the foreign key.
Otherwise, if it's just an integer, there is nothing wrong with adding an _id to the end of an otherwise acceptable column name.
Well I googled my question but I couldn't find anything or I it's not the correct question..
The issue is I need modify the primary_key name of the database :id with :another_id, in my project I need to use pgrouting and it contains several plsql functions and these functions uses the primary-key with the name gid and instead of modify the plsql functions is better change the id name, and I was thinking do this with a migration becouse I thought it's the rails way.
Is it possible, and how I can do this ??
Thanks in advance and sorry for my english.
Edit
create_table :pruebas, primary_key: :gid do |t|
t.string :name
t.timestamps
end
This do the trick, and with this active record generate and uses the pk as gid.
Sorry if my question was not clear.. Gracias por las respuestas.
To set the primary key yourself, when you create the table, you would do:
create_table(:table_name, primary_key: 'gid') do |t|
...
end
And you need to define the primary key name in your model:
self.primary_key = 'gid'
I don't have any experience using PostgreSQL or pgRouting, but I believe what you're looking for is a method for instructing ActiveRecord to use a different column as the primary key.
I believe you're looking for set_primary_key.
class Project < ActiveRecord::Base
set_primary_key "gid"
end
I have lots of situations where I'd like to have a non-autoincrement primary key when using Rails.
Example: I have one-to-one relationship between A and B. B describes some specific features added to A thus can't exist without A. So we have:
A has one B
B belongs to A
The natural thinking would be having B.A_id as primary key. So I tried create_table b, :id=>false in migration and set_primary_key :a_id in B's model, but it doesn't create actual primary keys in the database. And I want them (as well as foreign keys), as the database will be used not only by this Rails app.
If I create primary keys with execute they don't land in
schema.rb, which hurts. Now I'm thinking about a workaround: I can live without PK constraint as long as there's unique constraint for that column, so I can use Rails' add_index in the migration which seems more elegant.
Any suggestions?
A very similar question on StackOverflow suggests trying something like:
create_table(:b, :id => false) do |t|
t.integer :a_id, :options => 'PRIMARY KEY'
end