Add Top() method to Migration

[GoogleCodeExporter]

The problem: upgrading/downgrading the same stored procedure.

Suppose we have a stored procedure from migration 5 and on.
In 6, we change it a little bit so we need to add it to the migration. So
Migration6.Up() will drop the old one, install the new one.
Migration6.Down() should in theory drop the new one and install the old
one, but that creates a dependency, because we would need to copy the code
of the old version from Migration5 into Migration6 or reference it somehow.

So, would it be possible to have a Migration.Top() method that is called
after performing all migration steps are finished. It would be called only
for the migration that has become the latest one (the one "on top").

The implementation of Top() could then drop and reinstall ALL stored
procedures to their current versions, possibly reading them from external
files to keep things tidy. There would be no dependency on other migrations.

Original issue reported on code.google.com by tom...@gmail.com on 28 Aug 2008 at 10:18

[GoogleCodeExporter]

Just a thought: You don't have to copy the code between 2 different migrations. 
This is "just code".
Create a separate method call or a utility function that knows how to do the 
work that needs to be shared (the 
creation of the old Stored Procedure in this case). Basically, you don't have 
to do everything for a migration 
directly in a single method, you can compose that of other method calls. 

Original comment by geoffl...@gmail.com on 28 Aug 2008 at 1:16

[GoogleCodeExporter]

Yep, that would probably work in a single developer scenario, where I could 
remember
that the last time I changed the SP before Migration 6 was in Migration 4, so
Migration6.Down() would install the same one using a piece of shared code as you
suggested.

In a multi-developer scenario though, I may not know the last time the SP was
changed. I would have to go through the code of all the migrations to find out.

Now that I think about it again, another solution might be to find out the 
number of
the previous migration from the Migration code, so that when Migration6.Down() 
is
executed I can look up the file named 
/Migrations/5/InstallAllCurrentStoredProcs.sql
and run it. So when using the new timestamp numbering I just go backwards from 
the
current one in a directory listing or something... Hmmm..

Original comment by tom...@gmail.com on 28 Aug 2008 at 3:18

[GoogleCodeExporter]

Original comment by geoffl...@gmail.com on 5 Sep 2008 at 10:48

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I agree with tomovo that there should be something to support this scenario 
better,
but I don't think a Top() method is the right way to go.  Then I need to, as he 
said,
drop and reinstall all stored procs.  It would be better if migrator handled 
this.

Perhaps if there was a different type of migration for entities that are always
recreated likes procs and indexes which was given not just a version but also 
the
database object it worked on.  These wouldn't have an up and down, only an 
update. 
Then when going down from a given version, migrator could find the previous 
version
for that object and run it.  Of course there would need to be a way to delete 
the
object entirely too.

Original comment by WalkerCo...@gmail.com on 25 May 2010 at 8:41