IntranetFactory / migratordotnet

Automatically exported from code.google.com/p/migratordotnet
0 stars 0 forks source link

Down() method is not executed properly in v0.8.0 #95

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Create two migration classes prefixed with an "_" utilizing sequential
migration numbers instead of date/time stamps. e.g.

namespace test
{
  [Migration(1)]
  public class _001FirstMigration : Migration
  ...

2. Execute the migrations so that your db schema is at version 2
3. Try to migrate to version 0 of the schema

What is the expected output? What do you see instead?
I expect the output window to display messages for each migration that it
runs followed by the drop statements for the tables.  Instead, I see a
message for migration #2, but the drop statements are never called. 
However, migration #1's drop statements are actually called.

What version of the product are you using? On what operating system? With
what .NET implementation/version?
MigratorDotNet v0.8.0, Windows XP sp2, .NET Framework 3.5

What database and version are you seeing this issue on?
SQL Server 2005 Express

Please provide any additional information below.
I replaced the 0.8.0 binaries with the 0.7.0 binaries, and the problem was
gone.  

Original issue reported on code.google.com by curtismi...@gmail.com on 3 Mar 2009 at 3:45

GoogleCodeExporter commented 9 years ago
I also get this issue. Makes me a sad panda.

James

Original comment by james.sa...@gmail.com on 6 Mar 2009 at 7:50

GoogleCodeExporter commented 9 years ago
Do your versions tables have entries for both migrations 1 & 2? Version 0.8 
changed 
SchemaInfo so it stores every version. It's not backward compatible because of 
that 
change. (You can just insert a row for each applied migration 1..n to fix this.)

Only reason I ask, is that I just did this exact thing (rolled back to 0 and 
back up) 
and everything worked as expected using SQL Server 2005.

Original comment by geoffl...@gmail.com on 8 Mar 2009 at 2:46

GoogleCodeExporter commented 9 years ago
When I experienced the problem I confirmed that the SchemaInfo table had a 
record for
both migrations 1 & 2.  I was going against SQL Server 2005 Express, and I was 
using
the 0.8.0 release.  Are you using the 0.8.0 release, or a more recent nightly 
build?  

Original comment by curtismi...@gmail.com on 9 Mar 2009 at 8:55

GoogleCodeExporter commented 9 years ago
It seems like the issue occurs when I use square brackets to surround the table 
name.
 In my case, I'm setting a constant to the table name and using that in my migrations
(e.g. private string const MYTABLE = "[MyTable]"; ... 
Database.RemoveTable(MYTABLE);)
 I hope that helps.

Original comment by curtismi...@gmail.com on 9 Mar 2009 at 9:05

GoogleCodeExporter commented 9 years ago
I noticed this problem too. 
   RemoveTable("[User]") fails, but
   RemoteTable("User_")  succeeds.

Original comment by craig.go...@gmail.com on 18 Mar 2009 at 5:16

GoogleCodeExporter commented 9 years ago
Uploading patch to fix the bracket issue and to allow schema names. With this 
patch
the following should work.

RemoveTable("[dbo].[User]") 
RemoveTable("[User]")

Also has unit tests in the patch.

Original comment by tariqk...@gmail.com on 22 Jan 2010 at 5:51

Attachments:

GoogleCodeExporter commented 9 years ago
Svn 144
Applied patch

Original comment by geoffl...@gmail.com on 25 Mar 2010 at 10:27