Сначала код DbMigrator вызывает ошибку при сборке с разных машин - PullRequest
Новая
       42

Сначала код DbMigrator вызывает ошибку при сборке с разных машин

43 голосов
/ 01 марта 2012

У нас есть проект под СКМ. Когда я собираю его со своей машины и публикую на удаленном сервере через msdeploy, все работает нормально.

Когда мой коллега пытается сделать то же самое с тем же проектом, только что извлеченным из SCM, в инфраструктуре сущностей удаленного сервера 4.3.1 DbMigrator throws:

Автоматическая миграция не была применена, поскольку это приведет к потере данных.

Как оказалось, похоже, что человек, который делает первоначальную публикацию на удаленном сервере, является "победителем". Если мы отбросим базу данных на удаленном сервере, моя коллега может опубликовать ее, и меня заблокируют. Мои публикации приводят к той же ошибке выше.

Конфигурация для DbMigrator выглядит примерно так: 

        var dbMgConfig = new DbMigrationsConfiguration()
        {
            AutomaticMigrationsEnabled = true,
            //***DO NOT REMOVE THIS LINE, 
            //DATA WILL BE LOST ON A BREAKING SCHEMA CHANGE,
            //TALK TO OTHER PARTIES INVOLVED IF THIS LINE IS CAUSING PROBLEMS    
            AutomaticMigrationDataLossAllowed=false,
            //***DO NOT REMOVE THIS LINE,
            ContextType = typeof(TPSContext),
            MigrationsNamespace = "TPS.Migrations",
            MigrationsAssembly = Assembly.GetExecutingAssembly()
        };

Полагаю, это как-то связано с новой таблицей __MigrationHistory и неприглядной длинной шестнадцатеричной строкой, хранящейся в ее строках.

Я не хочу брать на себя полную ответственность за публикацию, чтобы жить. Что я могу высматривать?

Ответы [ 5 ]

8 голосов
/ 09 июля 2012

Мы изменили наш код с: 

        dbMgConfig.AutomaticMigrationDataLossAllowed = false;
        var mg = new DbMigrator(dbMgConfig);
        mg.Update(null);

до 

        dbMgConfig.AutomaticMigrationDataLossAllowed = true;
        var mg = new DbMigrator(dbMgConfig);
        var scriptor = new MigratorScriptingDecorator(mg);
        string script = scriptor.ScriptUpdate(sourceMigration: null, targetMigration: null);
        throw new Exception(script);

, чтобы мы могли наблюдать, какие изменения DbMigrator предпринимает на удаленном сервере.

В случае, описанном в начале этого вопроса (т.е. коллега выполняет загрузку, которая создает базу данных, а затем я выполняю загрузку, сгенерированную из того же источника на другом компьютере), генерируются следующие операторы SQL: 

ALTER TABLE [GalleryImages] DROP CONSTRAINT [FK_GalleryImages_Galleries_Gallery_Id]
ALTER TABLE [GalleryImages] DROP CONSTRAINT [FK_GalleryImages_Images_Image_Id]
ALTER TABLE [UserLightboxes] DROP CONSTRAINT [FK_UserLightboxes_Users_User_Id]
ALTER TABLE [UserLightboxes] DROP CONSTRAINT [FK_UserLightboxes_Lightboxes_Lightbox_Id]
ALTER TABLE [ImageLightboxes] DROP CONSTRAINT [FK_ImageLightboxes_Images_Image_Id]
ALTER TABLE [ImageLightboxes] DROP CONSTRAINT [FK_ImageLightboxes_Lightboxes_Lightbox_Id]
DROP INDEX [IX_Gallery_Id] ON [GalleryImages]
DROP INDEX [IX_Image_Id] ON [GalleryImages]
DROP INDEX [IX_User_Id] ON [UserLightboxes]
DROP INDEX [IX_Lightbox_Id] ON [UserLightboxes]
DROP INDEX [IX_Image_Id] ON [ImageLightboxes]
DROP INDEX [IX_Lightbox_Id] ON [ImageLightboxes]
CREATE TABLE [ImageGalleries] (
   [Image_Id] [int] NOT NULL,
   [Gallery_Id] [int] NOT NULL,
   CONSTRAINT [PK_ImageGalleries] PRIMARY KEY ([Image_Id], [Gallery_Id])
)
CREATE TABLE [LightboxImages] (
   [Lightbox_Id] [int] NOT NULL,
   [Image_Id] [int] NOT NULL,
   CONSTRAINT [PK_LightboxImages] PRIMARY KEY ([Lightbox_Id], [Image_Id])
)
CREATE TABLE [LightboxUsers] (
   [Lightbox_Id] [int] NOT NULL,
   [User_Id] [int] NOT NULL,
   CONSTRAINT [PK_LightboxUsers] PRIMARY KEY ([Lightbox_Id], [User_Id])
)
CREATE INDEX [IX_Image_Id] ON [ImageGalleries]([Image_Id])
CREATE INDEX [IX_Gallery_Id] ON [ImageGalleries]([Gallery_Id])
CREATE INDEX [IX_Lightbox_Id] ON [LightboxImages]([Lightbox_Id])
CREATE INDEX [IX_Image_Id] ON [LightboxImages]([Image_Id])
CREATE INDEX [IX_Lightbox_Id] ON [LightboxUsers]([Lightbox_Id])
CREATE INDEX [IX_User_Id] ON [LightboxUsers]([User_Id])
DROP TABLE [GalleryImages]
DROP TABLE [UserLightboxes]
DROP TABLE [ImageLightboxes]
ALTER TABLE [ImageGalleries] ADD CONSTRAINT [FK_ImageGalleries_Images_Image_Id] FOREIGN KEY ([Image_Id]) REFERENCES [Images] ([Id]) ON DELETE CASCADE
ALTER TABLE [ImageGalleries] ADD CONSTRAINT [FK_ImageGalleries_Galleries_Gallery_Id] FOREIGN KEY ([Gallery_Id]) REFERENCES [Galleries] ([Id]) ON DELETE CASCADE
ALTER TABLE [LightboxImages] ADD CONSTRAINT [FK_LightboxImages_Lightboxes_Lightbox_Id] FOREIGN KEY ([Lightbox_Id]) REFERENCES [Lightboxes] ([Id]) ON DELETE CASCADE
ALTER TABLE [LightboxImages] ADD CONSTRAINT [FK_LightboxImages_Images_Image_Id] FOREIGN KEY ([Image_Id]) REFERENCES [Images] ([Id]) ON DELETE CASCADE
ALTER TABLE [LightboxUsers] ADD CONSTRAINT [FK_LightboxUsers_Lightboxes_Lightbox_Id] FOREIGN KEY ([Lightbox_Id]) REFERENCES [Lightboxes] ([Id]) ON DELETE CASCADE
ALTER TABLE [LightboxUsers] ADD CONSTRAINT [FK_LightboxUsers_Users_User_Id] FOREIGN KEY ([User_Id]) REFERENCES [Users] ([Id]) ON DELETE CASCADE
CREATE TABLE [__MigrationHistory] (
   [MigrationId] [nvarchar](255) NOT NULL,
   [CreatedOn] [datetime] NOT NULL,
   [Model] [varbinary](max) NOT NULL,
   [ProductVersion] [nvarchar](32) NOT NULL,
   CONSTRAINT [PK___MigrationHistory] PRIMARY KEY ([MigrationId])
)
BEGIN TRY
   EXEC sp_MS_marksystemobject '__MigrationHistory'
END TRY
BEGIN CATCH
END CATCH
INSERT INTO [__MigrationHistory] ([MigrationId], [CreatedOn], [Model], [ProductVersion]) VALUES ('201203030113082_AutomaticMigration', '2012-03-03T01:13:08.986Z', 0x[removedToShortenPost], '4.3.1')

Как можно видеть, причина, по которой DbMigrator выбрасывает, заключается в том, что он пытается переименовать 3 таблицы, которые используются для объединения отношений many2many, путем инвертирования имен таблиц, которые они соединяют, например, GalleryImages в ImageGalleries или UserLightboxes до LightboxUsers.

Временное решение

Это похоже на ошибку в EF 4.3, где именование таблиц "ассоциаций", по-видимому, имеет неопределенный порядок. Учитывая, что порядок имен для таблиц такого типа выглядит неопределенным / неопределенным, мы подошли к этому под другим углом, используя свободный API, чтобы заставить EF использовать согласованные именования для сборок с разных машин: 

    protected override void OnModelCreating(DbModelBuilder modelBuilder)
    {
        base.OnModelCreating(modelBuilder);
        modelBuilder
            .Entity<Gallery>()
            .HasMany(p => p.Images)
            .WithMany(p => p.Galleries)
            .Map(c =>
            {
                c.MapLeftKey("Gallery_Id");
                c.MapRightKey("Image_Id");
                c.ToTable("GalleryImages");
            });
        modelBuilder
            .Entity<User>()
            .HasMany(p => p.Lightboxes)
            .WithMany(p => p.Users)
            .Map(c =>
            {
                c.MapLeftKey("User_Id");
                c.MapRightKey("Lightbox_Id");
                c.ToTable("UserLightboxes");
            });
        modelBuilder
            .Entity<Image>()
            .HasMany(p => p.Lightboxes)
            .WithMany(p => p.Images)
            .Map(c =>
            {
                c.MapLeftKey("Image_Id");
                c.MapRightKey("Lightbox_Id");
                c.ToTable("ImageLightboxes");
            });
    }

После установки ошибка исчезнет.

2 голосов
/ 24 апреля 2013 
 public Configuration()
        {
            AutomaticMigrationsEnabled = true;
            AutomaticMigrationDataLossAllowed = true;
        }
1 голос
/ 20 августа 2013

Я получаю ту же ошибку, поэтому сгенерировал скрипт и запустил его в Query Analyzer.Оказывается, проблема длины ключа:

Внимание!Максимальная длина ключа составляет 900 байтов.Индекс PK_dbo .__ MigrationHistory имеет максимальную длину 1534 байта.Для некоторой комбинации больших значений операция вставки / обновления завершится неудачей.

Похоже, что команда EntityFramework знает об этом:

http://entityframework.codeplex.com/workitem/1216

Не уверен, чтопроблемы это вызовет .....

0 голосов
/ 22 января 2019

У меня была действительно странная ошибка, похожая на эту для Entity Framework 6.2.0.

Configuration.cs: 

public class Configuration : DbMigrationsConfiguration<ApplicationDbContext>
{
    public Configuration()
    {
        AutomaticMigrationsEnabled = false;
        AutomaticMigrationDataLossAllowed = false;
    }
...
}

Приведенный ниже код вызвал StackOverflowException на одной машинено работал нормально на другом. 

var migrator = new DbMigrator(new Configuration());
if (migrator.GetPendingMigrations().Any())
{
    migrator.Update();
}

Решил, обновив его следующим образом: 

Database.SetInitializer(new MigrateDatabaseToLatestVersion<ApplicationDbContext, Configuration>());
0 голосов
/ 10 августа 2013

Я также столкнулся с этой проблемой. Как ни странно, рассматриваемая таблица не содержит абсолютно никаких данных, то есть она пустая, что-то, что Code First даже не проверяет при сообщении о том, что при применении миграции произойдет потеря данных.

...