I have a semi-grand plan for some changes to migrations. Mostly this
is motivated by the upcoming 3.0 release and wanting to get migrations
in engines working.
1. Don't skip migrations with version numbers lower than current.
I only recently tripped over this, but apparently it's been
On Sun, Mar 7, 2010 at 4:54 PM, Josh Susser j...@hasmanythrough.com wrote:
I have a semi-grand plan for some changes to migrations.
+1 on all points.
I reviewed rails.lighthouseapp.com/projects/8994/tickets/2058, and
your solutions seem to cover all bases (someone speak up if it
doesn't). I
On Sun, Mar 7, 2010 at 3:54 PM, Josh Susser j...@hasmanythrough.com wrote:
I have a semi-grand plan for some changes to migrations. Mostly this is
motivated by the upcoming 3.0 release and wanting to get migrations in
engines working.
1. Don't skip migrations with version numbers lower than
On Mar 7, 2010, at 5:49 PM, Jeremy Kemper wrote:
I'm not sure about this one.
I have a plugin with migrations for its own database. I want those to
run and be managed in their own universe. This works well today using
our existing tools: just override the connection class method on the
On Sun, Mar 7, 2010 at 8:28 PM, Josh Susser j...@hasmanythrough.com wrote:
There's also the improbable but pathological case where a migration in an
engine has the same version number or class name as one in the main app or
another engine. Now that I've said that I realize that migrations in
On Sun, Mar 7, 2010 at 6:49 PM, Jeremy Kemper jer...@bitsweat.net wrote:
I have a plugin with migrations for its own database. I want those to
run and be managed in their own universe. This works well today using
our existing tools: just override the connection class method on the
migration.
