2

We are working with entity framework 4.1 - code first. We need to be able to name our constraints and not have their names auto-generated by SQL Server. Is this possible?

We need: PK_Users_UserId, Not: PK_Users_87329729C

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
Mark Meisel
  • 851
  • 2
  • 12
  • 24

2 Answers2

3

The short answer is no. The longer answer is about meaning of the code first. Code-first means you are not interested in the database - you just let EF to create some and that is all what you need. It allows you defining names for tables and columns (it is useful especially when working with existing databases) but that is all.

If you need to work with database in such level you need database-first approach. Abusing code first to name constraints is possible but it is terribly hard and complex (it requires dropping old constraints after creation and create a new ones - example is here).

Community
  • 1
  • 1
Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • Thanks, that is what I feared. The issue we are experiencing is comparing a dev database to staging database, and trying to script the changes. The constraints, although having the same purpose, are named differently, therefore, the comparision script is useless. Any ideas on how to move changes from dev to staging without dropping/recreating the staging database? – Mark Meisel Dec 12 '11 at 18:16
  • 2
    I do not agree with the notion that *"[...] you are not interested in the database"*. ORMs are an abstraction, and they help you think at a higher level, but at the end of the day, the DB matters. Unlike EF, NH for example allows you to name your keys using whatever convention you want. – Diego Mijelshon Dec 13 '11 at 01:23
  • @DiegoMijelshon And I disagree with you, so it seems like it's a matter of taste. In a DDD approach the database doesn't really matter. Your POCOs and your business logic are the core of it. DALs should be exposed through a common interface and switchable, so the same BLL and upper layers (UI) don't know what's underneath: could be sql server, mysql, an xml file, an excel spreasheet, a mocking framework, whatever. As long as the DAL respects the contract, all is fine. So in this approach the DB doesn't really matter, it's just a tool, an implementation of what is important, the abstraction. – Matteo Mosca Dec 13 '11 at 08:25
  • @MatteoMosca *"And I disagree with you, so it seems like it's a matter of taste"* -> It's neither a competition, nor a vote. Experience shows that you can abstract the DB all you want, and you can isolate the higher layers from it, but when reality kicks in and your customers complain about performance, you have to start considering indexes, roundtrips, etc. – Diego Mijelshon Dec 13 '11 at 10:10
  • I never stated that you shouldn't care about performance, indexes, PKs , UKs, FKs, constraints, etc. But you do it in the appropriate place. In your DALs if you're using a good ORM (like EF 4.2 or NHibernate) you can specify all database specific stuff to improve performance. The thing is, this stuff is really DB specific, so it should not concern upper layers. The day you construct a DAL that uses XML files, you don't have those concepts. – Matteo Mosca Dec 13 '11 at 10:36
1

Could you run some raw sql to rename them after creation? You may need to disable the EdmMetadata convention.

context.Database.ExecuteSqlCommand(
  @"DECLARE @pk sysname
    SELECT @pk = name FROM sysobjects WHERE parent_obj = object_id('users') and xtype = 'pk'
    EXEC sp_rename @pk, 'pk_users_UserId'
");
Betty
  • 9,109
  • 2
  • 34
  • 48
  • I did something similar. When EF creates the database we've implemented some code in Seed() which loops through the primary key constraints and renames them to PK_[table name]. This solution has worked for us but I'd like to see the ability to explicitly name constraints through the fluent api. P.S. We left the EdxMetadata table alone, I use that to determine if the model has changed (thus forcing the drop/recreate of the database). – Mark Meisel Dec 17 '11 at 23:04