We have a table which has a composite primary key consisting of two foreign keys. I know that this should work on EF 4.0 but we get an update exception when trying to insert the referenced entities when using EF 3.5.
I tried to look for confirmation whether or not EF 3.5 supports this but the answer seems to always be "Yes, EF 4.0 supports this".
So I'm asking here:
Does entity framework 3.5 support composite keys made up from foreign keys?
Related
I am using EF core 2.0 and using scaffolding reverse engineering database first to generate models.
some of tables does not have any primary key and EF Unable to generate entity type for table.
Any advice how can I do this other then adding manually.
So far either Entity Framework or Entity Framework Core does not support generating table from EF/EF Core model class without primary key.
But this is a requested feature in Entity Framework Core. Here is the details about it:
Allow code generation for tables without a primary key
You could upgrade to EF core 3.0 which is currently in preview, that is now possible.
Are there already mapping-annotations (attributes) for mapping foreign keys?
If no, are such annotations planned?
I've seen, that there is still a fluent-api for mapping foreign keys, but I have not found mapping-attributes for this Task.
This is not implemented yet. You can track the work here https://github.com/aspnet/EntityFramework/issues/107
Entity Framework 4.0 wasn't able to create auto-incremented integer identity keys with SQL Compact 3.5, which meant I had to use GUIDs instead--sort of like using a shotgun to kill a fly. Does anyone know if this problem has been fixed with the release of SQL Compact 4.0? Can I use identity keys with EF4 and SQLCE4, or am I still stuck with GUIDs? Thanks.
Yes, this has been fixed in addition to many other improvements:
- Code First, Paging, Server Generated Keys
http://blogs.msdn.com/b/sqlservercompact/archive/2011/01/12/microsoft-sql-server-compact-4-0-is-available-for-download.aspx
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.