I want to put all app migrations in a plugin. And then when I run
rake db:migrate
and as the command is not able to find migrations in
"App\db\migrate" directory (the default one) I want it to be redirected
to look for migration files in my plugin and use them from that
location.
My questions are:
1) Are there some predefined rails hooks? Something like a method
migration_missing(find_migration_here)
2) If there are no special hooks, is it possible to implement the
behavior without much code or hacking Rails?
private
def set_author
self.author = User.find_or_create_by(name: author_name)
end
I cannot understand how "author_name" parameter appears in the model.
"author_name" parameter doesn't belong to model. It is from params, from
a form. So somehow it has to be passed to the model. But how?
attr_accessor is not attr_accessible. Why is it there? What does it
mean?
The table "posts" for the model Post is as follows:
When you save the post, that's when it calls the #set_author method,
which either finds an existing author with the name given, or creates a
new one, which is connected to the new post record with self.author.
When the save actually happens, AR is smart enough to know to hook up
self.author.id with author_id in the Post table.
You *can* do it the other way around, but it's clearly more work, since
ActiveRecord/Arel is doing all that for you.
When you save the post, that's when it calls the #set_author method,
which either finds an existing author with the name given, or creates a
new one, which is connected to the new post record with self.author.
It has been quite a break-through for me today
I used to do queries step by step, one by one, outside of model and then
assemble results together in one final Mode.create/save() method. All is
done in transaction but outside a model.
But isn't it strange, isn't it quite illogical that one model is
responsible for creating an absolutely different other model? In this
example the Post model is responsible for creating an instance of the
User model. And more than that, all the logic of creating a new User
instance is located inside of the Post model. It is against the idea of
AR pattern where each model is responsible for its own behavior.
But it is a rhetorical question from me. The way Rails offers do save
objects is pretty convenient. I'm glad I've understood it today.
You *can* do it the other way around, but it's clearly more work, since
ActiveRecord/Arel is doing all that for you.
> see the author_name up there?
>
> When you save the post, that's when it calls the #set_author method,
> which either finds an existing author with the name given, or creates a
> new one, which is connected to the new post record with self.author.
It has been quite a break-through for me today
I used to do queries step by step, one by one, outside of model and then
assemble results together in one final Mode.create/save() method. All is
done in transaction but outside a model.
But isn't it strange, isn't it quite illogical that one model is
responsible for creating an absolutely different other model? In this
example the Post model is responsible for creating an instance of the
User model. And more than that, all the logic of creating a new User
instance is located inside of the Post model. It is against the idea of
AR pattern where each model is responsible for its own behavior.
But it is a rhetorical question from me. The way Rails offers do save
objects is pretty convenient. I'm glad I've understood it today.
> You *can* do it the other way around, but it's clearly more work, since
> ActiveRecord/Arel is doing all that for you.
I haven't really gone through them to find the differences, but you can
also look at the edgeguides version of those pages, too. Very helpful,
as are all the guides, with deep reading and re-reading. I tend to learn
something knew each time I go through them.
I used to do queries step by step, one by one, outside of model and then
assemble results together in one final Mode.create/save() method. All is
done in transaction but outside a model.