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.
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 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 :-)
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
I created a new model in my rails app. Since it's a one-to-one relation with another table, there's no need for the new model to have an id column. Everything is working fine, but for some reason, all of my Shoulda tests on this model are failing. For example:
should_validate_presence_of :first_name
is throwing this error:
ActiveRecord::StatementInvalid: Mysql::Error: Unknown column 'my_new_table.id'
in 'field list': SELECT `my_new_table`.id FROM `my_new_table` WHERE
(`my_new_table`.`some_other_column` IS NULL) LIMIT 1
Does Shoulda require an ID column? If so, is there a way around this?
Did you alias the primary key for Rails purposes?
set_primary_key :my_fk_id
Rails expects your models to have an integer id column as a primary key. You can set it to the foreign key like #MattMcKnight suggests but I'd recommend you create the id column even if you don't strictly need it. In my experience it will save you tons of headaches like this, with basically no downside.
Did you run rake db:migrate and rake db:test:prepare after you created the new model?
All tables require an id column that's just the way that ActiveRecord works. As MattMcKnight points out, you can designate another column as the primary key. You can also specify that a table have no id column is creatied by providing :id => false as an option to create_table.
Matt's answer covers renaming the primary key in the model definition. Here's how to do it in a migration.
Note, providing the primary key option without giving the id option as false means that you do not have to add to column's definition to the block. Rails will create it for you. And automatically use it in any join tables.
Example:
class CreateTableWithOUtID < ActiveRecord::Migration
def self.up
create_table :my_new_table, :primary_key => :another_table_id do |t|
t.string :some_other_column
end
end
def self.down
drop_table, :my_new_table
end
end