How can I write a migration file to add an option to an existing model relationship? The existing table data must be preserved.
For example, I have existing:
class Chapter < ApplicationRecord
belongs_to :org
end
Which I want to update to:
class Chapter < ApplicationRecord
belongs_to :org, touch: true
end
How do I write the migration file for this? (Or for any other reference options changes?)
Would add_reference update the existing column? or add a new one?
class AddChapterToOrg < ActiveRecord::Migration
def change
add_reference :org, :chapter, touch: true
end
end
touch: true is an option to the belongs_to method and tells Rails to update the associated object's timestamp when the current object's timestamp is updated. This touch is handled by Rails and not by the database engine.
That said, when you add touch: true to a belongs_to association then there is no need to run a database migration because the database schema doesn't need to change to support this.
Related
I've created a new migration to add a new table. Lets call it
new_items which creates a new table.
in the migration, i've specified that the relationship with another table
t.belongs_to :parent
In my model,
class NewItem < ApplicationRecord
belongs_to :parent
class Parent < ApplicationRecord
has_many :new_items, :dependent => :destroy
So when I run all migration from scratch, there is a failure on an older migration
"could not find table 'new_items'"
in the failed migration, this is the line that where the problem lies
def up
Parent.where(name: "TestName").destroy_all
end
there is something wrong with my Parent model, as when i remove this following line it runs to completion
has_many :new_items, :dependent => :destroy
I know the issue is with the relationship between Parent and NewItem, but not sure how its best fixed
I can kinda see why its happening, but not sure how to resolve it while still keeping the relationship between the tables
Whenever using your ActiveRecord models in migrations, it is wise to define them within these migrations, so any changes to your models in the future won't break old migrations.
class Parent < ApplicationRecord; end
or in a nicer way, if your class does not need to do anything
Parent = Class.new(ApplicationRecord)
added inside your migration class should fix your issue.
Side note: if you simply want to delete all the records from parents table, it would be better to call to call Parent.delete_all in your migration. This would also solve the issue, but adding models to migrations is good practice.
You should not use ActiveRecord models in the migration. ActiveRecord doesn't like when Ruby class and schema doesn't match. And it can happens if multiple migration need to be run.
I suggest to only use SQL queries in migration.
def up
execute <<-SQL
DELETE FROM parent WHERE name = "TestName";
SQL
end
I am trying to understand Rails and I dont understand how I declare the model attributes correctly. For now my user class is looking like this:
class User < ActiveRecord::Base
has_many :users # Friends
end
By Googling I have understand that before Rails 4 one could determine attributes with the attr_accessible, like this:
attr_accessible :firstname, :lastname, :age, :sex
But this seems to be deprecated, how can I do that same thing in Rails 4?
has_many :users is not a model attribute, its model association. It means model User can have many User objects, which is incorrect. (also does not make sense even literally)
What attr_accessible does?
Specifies a white list of model attributes that can be set via
mass-assignmen
To add attributes to a model, you need to generate migrations.
Example, lets add name attribute to users:
rails generate migration AddNameToUsers #creates a migration file to add `name` column to `users` table
followed by:
rake db:migrate # executes migration file creating `name` column in `users` table
Now you can access these attributes simply as:
user = User.new
user.name
Again, if you want to mass-assign this attribute at some point of your code, you will need to specify this in your class with attr_accessible, as in your original example.
I have an existing legacy Firebird database with nonstandard table and field names.
I would like to write a Sinatra app that can access it and display information. I've seen stuff like dm-is-reflective that appears to work when a database has proper naming conventions, but how do I use DataMapper (or ActiveRecord whichever is the easiest) to access those tables?
For example, assuming I had these two tables:
Bookshelfs
shelf_id: integer
level: integer
created: timestamp
Book
id: integer
id_of_shelf: integer
title: string
pages: integer
Something like with odd naming conventions that don't follow any set pattern and where one table's record might "own" multiple entries in another table even though there is not foreign_key assigned.
How would you set up datamapper (or activerecord) to communicate with it?
Look in to this gem to get setup with ActiveRecord on Sinatra:
https://github.com/bmizerany/sinatra-activerecord
As for how to define the relations, activerecord can do this easily.
class Book < ActiveRecord::Base
belongs_to :bookshelf, :class_name => 'Bookshelf', :foreign_key => 'id_of_shelf'
end
class Bookshelf < ActiveRecord::Base
has_many :books, :class_name => 'Book', :foreign_key => 'id_of_shelf'
end
Assuming you figured out how to connect to your legacy database using ActiveRecord's Firebird adapter, the next thing I would do is define a view on top of each table, e.g.
CREATE VIEW books AS SELECT * FROM Book;
CREATE VIEW bookshelves AS SELECT * FROM Bookshelfs;
This way you can simply define models Book and Bookshelf in ActiveRecord as per usual and it will find everything in the right place inside the database.
I am following the guide at http://guides.rubyonrails.org/association_basics.html
and I have created
class Customer < ActiveRecord::Base
has_many :orders, :dependent => :destroy
end
class Order < ActiveRecord::Base
belongs_to :customer
end
but executing #order = #customer.orders.create() results in
unknown attribute: customer_id
Do you know why does this error occurs? And more importantly Is there a hidden reason for all the guides for has_many to drive you insane with showing this example, but non of them to be actually working :)
You need to add customer_id column to orders table.
For that you have to run the migration -
rails g migration add_customer_id_to_orders customer_id:integer
then
rake db:migrate
You're going to have to add a customer_id column to your orders table.
ActiveRecord doesn't know which customer to fetch for the relating order.
Try rails g migration AddCustomerIdToOrders customer_id:integer (don't forget db:migrate).
Sounds like you forgot to run your migrations. From the console and within the root directory of your rails project, run rake db:migrate to ensure rails has generated all the backing tables and columns for your associations and models.
I'm just getting started with DataMapper and I'm trying to figure out why you need to specify a has and a belongs_to.
For instance, look at the example on the DataMapper website. Isn't this redundant? If Post has n comments, then doesn't Comment automatically belongs_to post? Why do I have to specify this?
class Post
include DataMapper::Resource
property :id, Serial
has n, :comments
end
class Comment
include DataMapper::Resource
property :id, Serial
property :rating, Integer
belongs_to :post # defaults to :required => true
def self.popular
all(:rating.gt => 3)
end
end
You specify both sides of the relationship only when you want to use the methods generated by the extra specification. It's completely optional: If you never need to get to the Post from the Comment (e.g. #comment.post), you won't have to specify the belongs_to relation in Comment.
One advantage is that your instances are a bit cleaner because in Comment the additional methods are not autogenerated. On the other hand, if you need them, those extra methods would not bother you.
See also the documentation about associations in ActiveRecord.
That gives you the methods to access the relational object easily. Such as #post.comments #comment.post. I see what you mean, applying has_many could imply the belongs_to. Though given the developer overhead to add the belongs_to, is probably better than adding more system overhead to dynamically add the methods to the right class.
Another thing would be when using the has_many relation ship through another has_many relationship. That would cause odd belong_to relationships, and would probably cause issues with the SQL.
For example:
class User < ActiveRecord::Base
has_many :roles, :through => :roles_users
has_many :roles_users
end
The RolesUser being a join table that has belongs_to for the both the user and the role models. Implying the belongs to in this case would then add a belongs_to to the role model to a user. Nor does this not make sense, it also wouldnt work due to the lack of the database column being there. Of course this could be adjusted when the through option is there, but again this would highly raise the complexity of the code when it's not needed. As Daan said in his answer, you do not need both for it to work, it's optional.
I'd like to add to these good answers that if you have required dm-constraints (directly or via data_mapper) and use auto_migrate!, then belongs_to will automatically add foreign key constraints at the database level, whereas has alone will not do this.
e.g.:
require 'data_mapper'
class Post
include DataMapper::Resource
property :id, Serial
end
class Comment
include DataMapper::Resource
property :id, Serial
belongs_to :post
end
Produces this (via MySQL adapter):
~ (0.140343) CREATE TABLE comments (id INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
post_id INT(10) UNSIGNED NOT NULL, PRIMARY KEY(id)) ENGINE = InnoDB
CHARACTER SET utf8 COLLATE utf8_general_ci
~ (0.234774) CREATE INDEX index_comments_post ON comments (post_id)
~ (0.433988) ALTER TABLE comments ADD CONSTRAINT comments_post_fk
FOREIGN KEY (post_id) REFERENCES posts (id) ON DELETE NO ACTION ON UPDATE NO ACTION
If you use has n, :comments within Post but choose not to include belongs_to :post within Comment, the post_id column in the comments table will still be created and indexed, but no foreign key constraint will be added.