Unique Constraints (Unique Indexes)


Support unique constraints on non-key columns
Closed Dec 5, 2016 at 10:32 PM by RoMiller
EF Team Triage: We are transitioning this project to GitHub (https://github.com/aspnet/EntityFramework6). As part of this transition we are bulk closing a large number of issues in order that our new issue tracker will accurately reflect the work that our team is planning to complete on the EF6.x code base.

Moving forwards, our team will be fixing bugs, implementing small improvements, and accepting community contributions to the EF6.x code base. Larger feature work and innovation will happen in the EF Core code base (https://github.com/aspnet/EntityFramework). Closing a feature request in the EF6.x project does not exclude us implementing the feature in EF Core. In fact, a number of popular feature requests for EF have already been implemented in EF Core (alternate keys, batching in SaveChanges, etc.).

This is a bulk message to indicate that this issue was closed and not ported to the new issue tracker. The reasons for not porting this particular issue to GitHub may include:
• It was a bug report that does not contain sufficient information for us to be able to reproduce it 
• It was a question, but sufficient time has passed that it's not clear that taking the time to answer it would provide value to the person who asked it 
• It is a feature request that we are realistically not going to implement on the EF6.x code base
Although this issue was not ported, you may still re-open it in the new issue tracker for our team to reconsider (https://github.com/aspnet/EntityFramework6/issues). We will no longer be monitoring this issue tracker for comments, so please do not reply here.


Deus42 wrote Aug 8, 2012 at 2:15 PM

Guyz, srsly?

realstrategos wrote Sep 19, 2012 at 2:28 PM

agreed ...

jez9999 wrote Nov 5, 2012 at 10:01 AM

This issue basically seems to be a subset of issue #57 - Allow indexes to be specified using attribute/fluent API. A unique constraint just uses a unique index to enforce the constraint anyway, so I suggest people voting for this issue vote for issue #57.

AndriySvyryd wrote Nov 7, 2012 at 9:19 PM

While SQL Server may use a unique index to enforce a unique constraint it's not the whole story.

This work item is about creating unique constraints so that they could be used in FK relationships.

Work item #57 is just about creating indexes.

So, even though they are related, neither is a subset of the other.

SimonLampen wrote May 6, 2013 at 2:30 AM

This work item is about creating unique constraints so that they could be used in FK relationships.
all I want to be able to do is have some flexibility around FK relationships so we don't have to reduce our database schema to single column primary key relationships everywhere. Composite column unique keys are common. Please help us by supporting them or at least point out why they are so hard to support.
This issue is the 3rd most requested on uservoice but it keeps getting bumped.

divega wrote Aug 14, 2013 at 10:13 AM

Note for triage: we discussed recently about trying to at least start this work in the next version.

microchip78 wrote Aug 21, 2013 at 12:50 AM

would like to see the unique constraint implemented from the entitytypeconfig class on specific property ...

dlandi wrote Sep 15, 2013 at 12:13 AM

Hello Entity Framework Team,

Would love to see work started on this...

I was really surprised when an Association was not generated for ALL of my Foreign Keys in the Entity Model.

Seems like a major hole...


kxag wrote Nov 15, 2013 at 12:58 PM

I m trying to model a database in which i had to change primary keys in order to use TPH inheritance and then the foreign key relations were broken. Entity framework is not very flexible yet. Nor 1 -1 realtions work this way ... sad...

tidyui wrote Dec 6, 2013 at 11:44 AM

Any idéa of if/when this will be implemented? I'm (and probably many more) stuck with inserting plain SQL into my database seed to create these indexes.

TonyBao wrote Jan 14, 2014 at 3:30 PM

Any updates on this issue?

mattcsharp wrote Jan 27, 2014 at 9:36 PM

An additional side effect of this issue is that 1:0..1 associations aren't modeled correctly in a SQL database, as referenced here: https://entityframework.codeplex.com/workitem/1468

Thank you

csharperhd wrote Mar 11, 2014 at 11:29 PM

why is this still not in EF.

bartelia wrote Mar 17, 2014 at 6:35 PM

Agreed on the importance of this issue.

Use case:
'root' table - contains a two column, composite primary key.
An 'associated' table links to the root table via an ID that is not the two composite Pk. The ID is unique and carries an appropriate index (It could even be a RowGuid of the root table).

Now you wish to flatten two tables together but cannot as the associated table is related to the root table NOT via the pk.

ehasson wrote Mar 18, 2014 at 12:56 AM

This is an important feature.

weitzhandler wrote Apr 2, 2014 at 3:12 AM

Very compelling!!!

jakesteele wrote Jun 19, 2014 at 4:57 PM

Ran into a case where my data is coming in from salesforce using different String ids then my internal auto generated ids, this would have been very helpful if it was implemented.

jonjw19 wrote Jun 30, 2014 at 7:10 PM

This issue is really complicating new adoption of EF at my company, how is there still no ETA for such a huge problem?

jimmyzimms wrote Jul 1, 2014 at 4:58 PM

Agreed with jonjw19. This is just ORM fundamentals here folks. I understand that not everything can be done at once and that huge amounts of legacy cruft exists in this codebase due to the legacy of older EF versions that in retrospect were bad design or incompletely thought out design choices but the lack of a clear roadmap is just criminal.

dotcom wrote Feb 11, 2015 at 10:26 AM

This issue has been around for 2.5 years and still nothing done?

tonkajuris wrote May 16, 2015 at 3:26 PM

Viewing Julie's course on EF6 and this work item is referenced.

TerminalSamurai wrote May 26, 2015 at 7:26 PM

How is this still an issue, it's #2 on the list for votes and is comming up on 3 years since this was opened. There are so many reasons to have this added.