Hook for "rake db:migrate" to redirect command to search for migrations in plugin / gem?

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 (or gem) 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.rb”)

  1. If there are no special hooks, is it possible to implement the
    behavior without much code or hacking Rails?

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 (
Getting Started with Engines — Ruby on Rails Guides ) instead. Engines can (among
other things have migrations)

Fred

Plugins are deprecated. Write an engine (
Getting Started with Engines — Ruby on Rails Guides ) 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
(Getting Started with Engines — Ruby on Rails Guides):

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 L. [email protected] wrote:

private
mean?
@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?

Hummm, no.

@post = Post.new(:title => “title”, :text => “text”, :author_name =>
“Wins L.”)
@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.

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:

Wins L. [email protected] wrote:

assemble results together in one final Mode.create/save() method. All is
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.

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:

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