I have a problem with the naming of some primary keys in the database. On my development system the primary key constraints are named PK_FullTableName. Now on a production system the constraints are all named PK_PartofTableName_3214EC27164452B1 (with different Hex characters for each table).
The problem I have are the migrations. I have a code-based migration, that should change the primary key of a table and therefore has to drop the old constraint/primary key with DropPrimaryKey("FullTableName", new[] { "Field1", "Field2" });
On my development system everything works fine, on the productive system I get an SQL exception that the constraint PK_FullTableName could not be found and I cannot migrate.
I don´t know why Entity Framework names the constraints different on these two systems. Does anyone know what this behavior is depending on? Is this naming from the EF or from the database(MSSQLExpress)? And is there a workaround?
Related
According this documentation page (Association Relationship), it seems that CodeFluent Entities generate Foreign keys in NOCHECK mode by default on One to Many and Many to Many relations. On the other hand, the Foreign keys on One to One relations are created in CHECK mode.
I have several questions about that:
My understanding is that NOCHECK foreign keys are disabled. If so,
what is the purpose of creating all that disabled foreign keys ?
Is there a way (and an interest) to change that behaviour?
We have some One to One relations on our application but still, all the foreign keys are disabled on our database. Why is it so ?
thanks by advance.
The foreign keys gives you some informations about the scheme even if there are not enforced. Also it can be convenient during development to not get integrity errors when you update the database. In the documentation, it is said that it's for performance reasons, but I'm really not sure about this one.
Anyway, you can instruct CodeFluent Entities to check constraint by setting defaultPersistenceEnforce="true" on the project
<cf:project defaultPersistenceEnforce="true">
From the documentation
Note: By default referential integrity is not enforced for performance reasons. However, one can enable relationships enforcement globally by setting the defaultPersistenceEnforce attribute of the project node to true.
It's also possible to enforce a specific relationship instead of the whole project. One can do so by specifying the persistenceEnforce attribute to true on the relation property.
I am beginning playing with EF 6.x and I've got an annoying issue.
I've designed a database with simple User,Role,Permissions tables each one bond to another with classic many-to-many relation.
EF wants me to create primary keys in indirect tables (UserPermissions etc.)
but also wants me to make some mapping for those Primary Keys but I have no clue why.
Is there something wrong with my design or there Is a workaround to this issue?
Maybe Can I in some way use Unique index instead of Primary Key to satisfy EF?
There you have diagram to make it more clear:
Well, I'm embarrased that I've not came up to solution earlier.
Just added multicolumn Primary Key on columns referencing direct tables via foreign key.
e.g. CONSTRAINT pk_IdRole_IdPermission_RolePermissions PRIMARY KEY (IdRole,IdPermission)
2019 Update / TLDR; switch to Entity Framework Core (or whatever else)
While missing some "Features", EF Core properly honors Alternate Keys (aka Unique Constraints) in addition to Primary Keys and thus does a much better job of honoring Relational Algebra. YMMV otherwise; at least it supports many more SQL schemes correctly.
This support added was in the (very outdated) EF Core 1.0 release.. a bit disappointing that the original EF never had this design(ed!) flaw addressed.
This may be related to my other question - which seems to be that either:
Entity Framework is a terrible Relational Algebra mapper1 or;
(which I am hoping for) I am overlooking something with SSDL/CSDL and the EDMX model or EF mappings in general.
I have a Schema First model and the schema looks like this:
ExternalMaps
---
emap_id - PK
Melds
---
meld_id - PK
emap_id - >>UNIQUE INDEX<< over not-null column, FK to ExternalMaps.emap_id
For verification, these are scripted as the following, which should result in a multiplicity of ExternalMaps:1 <-> 0..1:Melds2.
ALTER TABLE [dbo].[Melds] WITH CHECK ADD CONSTRAINT [FK_Melds_ExternalMaps]
FOREIGN KEY([emap_id]) REFERENCES [dbo].[ExternalMaps] ([emap_id])
CREATE UNIQUE NONCLUSTERED INDEX [IX_Melds] ON [dbo].[Melds] ([emap_id] ASC)
However, when I use the EDMX designer to update from the database (SQL Server 2012), from scratch, it incorrectly creates the Association / Foreign Key relation as ExternalMap:1 <-> M:Meld.
When I try to change the multiplicity manually for the Meld (via the "Association Set" properties in the designer) side to either 1 or 0..1, I get:
Running transformation: Multiplicity is not valid in Role 'Meld' in relationship 'FK_Melds_ExternalMaps'. Because the Dependent Role properties are not the key properties, the upper bound of the multiplicity of the Dependent Role must be *.
(As with my other question, this seems to be related to Unique Constraints not being correctly registered/honored as Candidate Keys.)
How can I get EF to honor the 1 <-> 0..1/1 multiplicity, as established by the model?
1 While I hope this is not the case, I am having no end to grief when trying to get EF to map onto a perfectly valid RA model: LINQ to SQL (L2S) does not have this problem. Since my other question was not trivially answered for such a popular ORM, I am losing faith in this tooling.
2 It is by design that the FK is not the other way: "Though shalt not have nullable foreign keys." - It is also not the case that it's a "shared" PK as this answer from 2009 suggests as a fix.
I am using EF 6.1.1, VS 2013 Ultimate, and am not going to use any "OO subtype features" - if that changes anything.
EDIT sigh:
Multiplicity is not valid because the Dependent Role properties are not the key properties? (from 2011) - is this still the case for the EF "Microsoft-endorsed Enterprise-ready" ORM in 2014 2015?
At this rate the next time someone asks why EF wasn't used I'll have a large set of reasons other than "LINQ to SQL works just fine" ..
The problem is that Entity Framework (from EF4 through EF6.1, and who knows how much longer) does not "understand" the notion of Unique Constraints and all that they imply: EF maps Code First, not Relational Algebra *sigh*
This answer for my related question provides a link to a request to add the missing functionality and sums it up:
.. The Entity Framework currently only supports basing referential constraints on primary keys and does not have a notion of a unique constraint.
This can be expanded to pretty much all realms dealing with Unique Constraints and Candidate Keys, including the multiplicity issue brought up in this question.
I would be happy if this severe limitation of EF was discussed openly and made "well known", especially when EF is touted to support Schema First and/or replace L2S. From my viewpoint, EF is centered around mapping (and supporting) only Code First as a first-class citizen. Maybe in another 4 years ..
The re-design for a large database at our company makes extensive use of composite primary keys on the database.
Forgetting performance impacts, will this cause any difficulties when working with this db in Entity Framework 4.0? The database structure is unlikely to change and I'm not looking for "philosophical" debate but what are the practical impacts?
According to Jeremy Miller, "Composite key make any kind of Object/Relational mapping and persistance in general harder." but he doesn't really say why. Is this relavent to how Entity Framework 4.0 handles keys?
No, EF4 supports composite keys just fine.
The problem is a table with a surrogate key and composite keys. You can only set a single key on each model; that key can have multiple fields, but you can only have one from the designer standpoint. Not sure about manually editing xml or code only mapping.
You can set a field as an Identity and not a key if you need a composite and surrogate key on the same table. The Identity ( Id ) field won't be used by the ObjectContext or ObjectStateTracker but will increment and be queryable just fine though.
I have had problems with EF4 and composite keys. It doesn't support columns being used as components in more than one key in a join table.
See my previous question Mapping composite foreign keys in a many-many relationship in Entity Framework for more details. The nuts of it is that when you have a join table (describing a many-many relationship) where both of the relationships use a common key, you'll get an error like
Error 3021: Problem in mapping
fragments...: Each of the following
columns in table PageView is mapped to
multiple conceptual side properties:
PageView.Version is mapped to
(PageView_Association.View.Version,
PageView_Association.Page.Version)
The only way around it was to duplicate the column which defeats the purpose of having it there at all.
Good luck!
I know how to mark a group of fields as primary key in ADO.NET entities but i haven't found a way to declare unique constraints or check constraints.
Is this feature missing on the designer or on the framework?
Support for unique keys/constraints does not exist in ADO.NET Entities in v4.0, see the answer to "one-to-one association on a foreign key with unique constraint", where Diego B Vega says:
I know for sure we haven't added
support for unique keys other than
primary keys in 4.0.
He does, however, provide a possible workaround/hack (which comes with all the normal caveats):
As you are probably aware of, it is
often possible to “lie” to Entity
Framework and tell it in the SSDL, for
instance, that some unique key is the
primary key. I reckon this would work
very well if the actual primary key is
an surrogate key (i.e. an IDENTITY
column that was added for this
purpose) and you don’t even have to
map it in the model.