Hook for "rake db:migrate" to transfer command to plugin?

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?

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.

Plugins are deprecated. Write an engine ( http://guides.rubyonrails.org/engines.html ) instead. Engines can (among other things have migrations)

Fred

Plugins are deprecated. Write an engine (
http://guides.rubyonrails.org/engines.html ) instead. Engines can (among
other things have migrations)

Thank you. This is what I'm doing right now - creating an engine.

Could you please explain me (of course if you know) how this code in the
engine works. This is an example from Rails Engine tutorial
(http://edgeguides.rubyonrails.org/engines.html#using-a-class-provided-by-the-application):

attr_accessor :author_name
belongs_to :author, class_name: "User"

before_save :set_author

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:

Could you please explain me (of course if you know) how this code in the
engine works.

So, I've learned how it works.

The save statement should be as follows:

@post = Post.new({:author_name => "some_name"}, :without_protection =>
true)
@post.save!

And a new author will be created if there is no user with such a name in
the DB. Otherwise the user will be updated.

This helped me:
http://stackoverflow.com/questions/3136420/difference-between-attr-accessor-and-attr-accessible

Hummm, no.

@post = Post.new(:title => "title", :text => "text", :author_name =>
"Wins Lin")
@post.save!

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.
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.

tamouse m. wrote in post #1111882:

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 :slight_smile:
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 should read more about this Arel feature.

Thank you.

tamouse m. wrote in post #1111882:

> 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 :slight_smile:
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 should read more about this Arel feature.

* http://guides.rubyonrails.org/association_basics.html
* http://guides.rubyonrails.org/active_record_querying.html

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.

Thank you.

My pleasure. :slight_smile: