LinuxDoku / migratordotnet

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

Error removing columns with unique constraints #145

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1. Apply the upgrade migration below.
2. Downgrade the migration.

[Migration(2)]
public class Test_001 : Migration
{
    public override void Up()
    {
        Database.AddTable("TestTable", new Column("TestCol", 
DbType.Int32));
        Database.AddColumn("TestTable", new Column("TestCol1", 
DbType.Int32, ColumnProperty.Unique));
    }

    public override void Down()
    {
        Database.RemoveColumn("TestTable", "TestCol1");
        Database.RemoveTable("TestTable");
    }
}

What is the expected output? What do you see instead?

It should remove the column and table, but instead throws an exception on 
the downgrade:
System.Data.SqlClient.SqlException: The object 
UQ__TestTabl__0B0C76C503317E3D' is dependent on column 'TestCol1'.

What version of the product are you using? On what operating system? With 
what .NET implementation/version?

Migrator version: 0.9
OS: Windows 7
.NET: 3.5

What database and version are you seeing this issue on?

DB: Sql Server 2008 Express

Original issue reported on code.google.com by faede...@gmail.com on 17 Mar 2010 at 6:25

GoogleCodeExporter commented 8 years ago
I have verified that this problem occurs on SQL Server 2005 Developer Edition:
public override void Up()
{
    // ...
    Database.AddColumn("Person", "user_name", DbType.String, 25,
ColumnProperty.NotNull | ColumnProperty.Indexed | ColumnProperty.Unique);
    // ...
}

public override void Down()
{
    // ...
    Database.RemoveColumn("Person", "user_name");
    // ...
}

Result:

System.Data.SqlClient.SqlException: The object 'UQ__Person__0425A276' is 
dependent on
column 'user_name'.
ALTER TABLE DROP COLUMN user_name failed because one or more objects access 
this column.

Original comment by bow...@gmail.com on 19 Apr 2010 at 9:50

GoogleCodeExporter commented 8 years ago
I remember reading in the source/docs (forgot where) that implicitly creating an
unnamed constraint is a problem because you don't know the name of the 
constraint if
you need to delete it in the Down().  Looks like that's what's happening here.

I think you're better off explicitly creating the constraint with
AddUniqueConstraint(), and then explicitly deleting the constraint with
RemoveConstraint() in your Down().  Not only will it give the constraint a more
memorable name, but it will act as an extra check to make sure you're deleting 
the
column you intended to - maybe it's just my obsessive nature but I like that.

Original comment by hired.m...@gmail.com on 23 Apr 2010 at 7:46