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!
Related
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)
I'm using Entity Framework 5, code first approach. As there's no built in support for updating child entities in disconnected scenario, I'm building my own mechanism to do that. At some point I need to get the property of an entity with which it has a Foreign Key relationship with another (principal) entity. I've tried to get access to CSpace through
((IObjectContextAdapter)dbContext).ObjectContext.MetadataWorkspace.GetItems<MyEntity>(System.Data.Entity.Core.Metadata.Edm.DataSpace.CSpace)
but here I got a warning that said there's no implicit conversion between MyEntity and System.Data.Entity.Core.Metadata.Edm.GlobalItem.
I can't look for a property that has Foreign Key attribute because in most of my entities I use EF convention to get foreign keys automatically. So how one would go about finding which property is used for foreign key relationship.
Thanks to #octavioccl's post I was able to do what I want. So I was in the right path to look inside ObjectContext.
I want to create an entity in EF without a public key. The backing table has got a non-unique clustered key, but the data in the table conceptually doesn't have a unique primary key it can use.
It looks like EF really doesn't like this. Is there any way of getting EF to accept that the table has no primary key and make it work with it anyway, with no performance hit? I don't care if the result is read-only.
As I understand it, as the Entity Framework is based on the Domain Driven Design concept of Entities, each Entity by definition must have a unique identifier. If the concept which the data in your table represents does not conceptually have a unique identifier then it is not an Entity, in the sense intended by the framework.
With this in mind I'd define a Stored Procedure, make it available through my object context, then make the objects encapsulating this data available via a class which lazy-loads the data, manually maps it into the objects you're using and presents it in a read-only manner.
You may also be able to accomplish this by exposing a view and then mapping your entity to the view.
I'm currently working with a large database (approx. 500 tables) all without any foreign keys define.
My question is there an easy way to set up the relationships within entity framework (version 1 or 2) without doing it all manually?
Also some of the tables have a complex relationship type. For example a customer has a parentID but this can either link to another customer in the same table (customerID) or link to an account in an account table (accountID). Is this kind of relationship possible in entity framework?
If this is not possible or if anyone has any opinions on an alternative solution to Enitity Framework I'm more than open to ideas. Will nHibernate or active record be a better solution? Or will it be easier creating my own business object and data access?
Cheers
Simon
If you don't have any Foreign Keys defined, then there's no way for the Entity Framework to infer relationships. You'll have to define them manually.
As for your second question...no. That kind of relationship is not possible (it's also a poor design choice).
It sounds to me like, unless you want to refactor your database and implement a design that has Foreign Key relationships, you're going to have to hand roll your own Business Objects and Data Access Layer.
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.