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

[Wins Lin]

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?

--
Posted via http://www.ruby-forum.com/.

[Frederick Cheung]

On Saturday, June 8, 2013 3:28:56 PM UTC+1, Ruby-Forum.com User wrote:

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

[Wins Lin]

> 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:
---------------------------------
| id | title | text | author_id |
---------------------------------


So, the new @post has to be created this way:

@author = User.new(...some params...)
@post = Post.new(:title => "title", :text => "text", :author_id =>
@author.id)
@post.save!

But there is some "set_author" method. What is a magic is it with that
"set_author" method and :author_name parameter?

[Wins Lin]

> 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

[Tamara Temple]

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.

[Wins Lin]

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

[Tamara Temple]

* 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. :)