Plugin Migrations have their own version history. Their version numbers
are kept in a table called 'plugin_schema_info', which has 1 row per
plugin with migrations.
The script/generate plugin_migration generates client migrations that
place themselves sequentially at the end of the client migrations. So
in your example, the newly added core_wiki migration would get copied
into the client my_custom_wiki but would be numbered as client migration
007.
The script/generate plugin_migration uses the plugin_schema_info version
number associated with core_wiki to see how far your client has already
been migrated and then copies the un-executed migrations to the client.
Actually it doesn't copy them, it puts a placeholder migration that just
calls the migration on the plugin class, like:
class CoreWikiToVersion7 < ActiveRecord::Migration
def self.up
Rails.plugins["core_wiki"].migrate(7)
end
def self.down
Rails.plugins["core_wiki"].migrate(6)
end
end
However, I do believe that if you have copied migrations (such as this)
to the client previously, but not executed them yet, and run
script/generate plugin_migrations again you will get extra copies. I
haven't verified this though.
Trevor Rowe
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Daniel Wintschel
Sent: Tuesday, November 06, 2007 9:59 AM
To: [email protected]
Subject: [Engine-Users] Question about how engine plugin
handlesmigrations...
Hi all,
I have a question about how engines deals with migrations (really, I
could test this myself, but since I haven't used engines I was
wondering if someone might have a definitive or 'official' answer).
1) Let's say I have a core application (we'll call it core_wiki for
kicks) - and it has some views, models, controllers and migrations
that I turn into an engine / plugin... so I move my migrations (let's
say 001, 002 and 003) into the appropriate
vendor/plugins/core_wiki/db/migrate directory - and I'm off to the
races.
2) Now I run script/generate plugin_migration && rake db:migrate - and
I get my migrations copied over to my 'real' application (e.g. into
my_custom_wiki/db/migrate).
3) Let's say I now customize the my_custom_wiki APPLICATION (not the
engine functionality - but the actual application) - and I end up
adding a few migrations into the actual application (hypothetically
004, 005 and 006).
4) Now I come to a point where I want to add a few more features to
the core_wiki (which would be the vendor/plugins/core_wiki part).
These features requires some new migrations, which if I name in
sequence would also be migrations with names 004, 005 and 006 - since
the my_custom_wiki migrations (mentioned in step 3) were part of the
my_custom_wiki application, and not the core_wiki plugin. What now
happens when I run script/generate plugin_migration && rake db:migrate
again? Are the new core_wiki migrations copied over to my actual
applications db/migrate directory as 007, 008, 009? Is that all that
happens? Or is this not the type of situation that the Engine plugin
is supposed to be used for at all?
Basically the situation I have is that I have a core piece of software
that will be deployed to multiple clients.
Each client will require customizations of the software, which may
involve custom database migrations.
At the same time, I want to continue to build/develop/add features to
the core, and have the ability to easily deploy these new features,
bug fixes, etc. to each client (Yes - I know that a lot of care must
be taken when doing this - mostly I just want to know how the Engine
plugin will deal with the migration scenario I've described above).
If none of that makes sense, please forgive me and ask me to clarify -
it's still before 10am and I need some more coffee.
-daniel
_______________________________________________
Engine-Users mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.o
rg
_______________________________________________
Engine-Users mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
