2014-02-03 2 views
14

Я использую код MVC5 + Ef6 сначала с ASP.Net Identity 1.0 и хочу, чтобы таблицы были созданы в пользовательской схеме. то есть схемы, которая не является схемой dbo.Идентификация ASP.Net - использование пользовательской схемы

Я обращенная инженерия моего Databse с помощью электроинструментов Е.Ф. и задать имя схемы для всех других таблиц в классе отображения следующей

this.ToTable("tableName", "schemaName"); 

Я попытался сделать это для таблиц ASP.Net, но он сохранил давая мне массу ошибок, и в конце концов я сдался. Если я исключаю (обратные инженерные) таблицы ASP.Net Identity из моего проекта, они будут созданы, но всегда в схеме dbo

Кто-нибудь знает, как это сделать?

+0

Возможно, вы можете переписать классы и используйте 'TableAttribute ' – TGlatzer

ответ

13
public class MyDbContext : EntityDbContext<ApplicationUser> 
{ 
    public DbSet<ApplicationUser> Users { get; set; } 

    public MyDbContext() : base() 
    { 
    } 

    protected override void OnModelCreating(DbModelBuilder modelBuilder) 
    { 
     // You can globally assign schema here 
     modelBuilder.HasDefaultSchema("schemaName"); 
    } 
} 
+0

Это работает в том, что он создает таблицы в желаемой схеме, однако, когда я использую roleManager в коде, он ищет таблицы в схеме dbo. Есть идеи? – martin

+0

Хорошо, я заработал. У меня было два контекста: IdentityManagerContext и applicationContext, который наследует IdentityManagerContext. Я установил HasDefaultSchema в applicationContext, но должен был установить его в переопределении OnModelCreating в IdentityManagerContext. Когда я это сделал, все сработало.Thanks – martin

+0

@martin: Рад это слышать! ;-) –

4

Вот поздняя запись, поясняющая, что я сделал. Не уверен, есть ли лучший способ, но это ТОЛЬКО то, что сработало для меня.

Справедливости ради, у меня в моем контексте больше одной модели. Вот почему это было лучше для меня.

  1. Генерация таблиц в базе данных раньше времени (в то время как таблицы по-прежнему в «DBO»)
  2. Execute add-migration на ваш проект, и пусть это создать миграцию
  3. Изменить все схемы в вашей миграции кода до желаемой схемы
  4. Выполнить update-database, чтобы получить эти изменения обновляются
  5. Удалить исходный файл миграции (его хэш бесполезен для вас)
  6. Выполнить add-migration снова и пусть это создать новую миграцию
  7. Обновление OnModelCreating метода конфигурации с кодом ниже
  8. Запустите приложение и начать регистрацию пользователей

Примечание:
Вы НЕ хотите, чтобы это ,

// This globally assigned a new schema for me (for ALL models) 
modelBuilder.HasDefaultSchema("security"); 

КОНФИГУРАЦИЯ: OnModelCreating
Это назначается новая схема только для упомянутых таблиц

protected override void OnModelCreating(DbModelBuilder modelBuilder) 
{ 
    base.OnModelCreating(modelBuilder); 

    modelBuilder.Entity<ApplicationUser>().ToTable("AspNetUsers", "security"); 
    modelBuilder.Entity<CustomRole>().ToTable("AspNetRoles", "security"); 
    modelBuilder.Entity<CustomUserClaim>().ToTable("AspNetUserClaims", "security"); 
    modelBuilder.Entity<CustomUserLogin>().ToTable("AspNetUserLogins", "security"); 
    modelBuilder.Entity<CustomUserRole>().ToTable("AspNetUserRoles", "security"); 
} 

ИСХОДНЫХ МИГРАЦИИ выглядят как

public partial class Initial : DbMigration 
{ 
    public override void Up() 
    { 
     CreateTable(
      "security.AspNetRoles", 
      c => new 
       { 
        Id = c.String(nullable: false, maxLength: 128), 
        Name = c.String(nullable: false, maxLength: 256), 
       }) 
      .PrimaryKey(t => t.Id) 
      .Index(t => t.Name, unique: true, name: "RoleNameIndex"); 

     CreateTable(
      "security.AspNetUserRoles", 
      c => new 
       { 
        UserId = c.String(nullable: false, maxLength: 128), 
        RoleId = c.String(nullable: false, maxLength: 128), 
       }) 
      .PrimaryKey(t => new { t.UserId, t.RoleId }) 
      .ForeignKey("security.AspNetRoles", t => t.RoleId, cascadeDelete: true) 
      .ForeignKey("security.AspNetUsers", t => t.UserId, cascadeDelete: true) 
      .Index(t => t.UserId) 
      .Index(t => t.RoleId); 

     CreateTable(
      "security.AspNetUsers", 
      c => new 
       { 
        Id = c.String(nullable: false, maxLength: 128), 
        FirstName = c.String(nullable: false, maxLength: 250), 
        LastName = c.String(nullable: false, maxLength: 250), 
        Email = c.String(maxLength: 256), 
        EmailConfirmed = c.Boolean(nullable: false), 
        PasswordHash = c.String(), 
        SecurityStamp = c.String(), 
        PhoneNumber = c.String(), 
        PhoneNumberConfirmed = c.Boolean(nullable: false), 
        TwoFactorEnabled = c.Boolean(nullable: false), 
        LockoutEndDateUtc = c.DateTime(), 
        LockoutEnabled = c.Boolean(nullable: false), 
        AccessFailedCount = c.Int(nullable: false), 
        UserName = c.String(nullable: false, maxLength: 256), 
       }) 
      .PrimaryKey(t => t.Id) 
      .Index(t => t.UserName, unique: true, name: "UserNameIndex"); 

     CreateTable(
      "security.AspNetUserClaims", 
      c => new 
       { 
        Id = c.Int(nullable: false, identity: true), 
        UserId = c.String(nullable: false, maxLength: 128), 
        ClaimType = c.String(), 
        ClaimValue = c.String(), 
       }) 
      .PrimaryKey(t => t.Id) 
      .ForeignKey("security.AspNetUsers", t => t.UserId, cascadeDelete: true) 
      .Index(t => t.UserId); 

     CreateTable(
      "security.AspNetUserLogins", 
      c => new 
       { 
        LoginProvider = c.String(nullable: false, maxLength: 128), 
        ProviderKey = c.String(nullable: false, maxLength: 128), 
        UserId = c.String(nullable: false, maxLength: 128), 
       }) 
      .PrimaryKey(t => new { t.LoginProvider, t.ProviderKey, t.UserId }) 
      .ForeignKey("security.AspNetUsers", t => t.UserId, cascadeDelete: true) 
      .Index(t => t.UserId); 

    } 

    public override void Down() 
    { 
     DropForeignKey("security.AspNetUserRoles", "UserId", "security.AspNetUsers"); 
     DropForeignKey("security.AspNetUserLogins", "UserId", "security.AspNetUsers"); 
     DropForeignKey("security.AspNetUserClaims", "UserId", "security.AspNetUsers"); 
     DropForeignKey("security.AspNetUserRoles", "RoleId", "security.AspNetRoles"); 
     DropIndex("security.AspNetUserLogins", new[] { "UserId" }); 
     DropIndex("security.AspNetUserClaims", new[] { "UserId" }); 
     DropIndex("security.AspNetUsers", "UserNameIndex"); 
     DropIndex("security.AspNetUserRoles", new[] { "RoleId" }); 
     DropIndex("security.AspNetUserRoles", new[] { "UserId" }); 
     DropIndex("security.AspNetRoles", "RoleNameIndex"); 
     DropTable("security.AspNetUserLogins"); 
     DropTable("security.AspNetUserClaims"); 
     DropTable("security.AspNetUsers"); 
     DropTable("security.AspNetUserRoles"); 
     DropTable("security.AspNetRoles"); 
    } 
} 
+0

Намного лучше, чем использование .HasDefaultSchema() просто для изменения схемы на небольшом горстка столов – Brendan

+0

отличная информация по этому вопросу спасибо –

+0

Интересные вещи - но зачем нам прыгать через все эти обручи? Разумеется, он должен работать как есть? – noelicus

Смежные вопросы