Currently I have class hierarchy defined with the Code First approach as follows.
E.F. has autogenerated a nvarchar(128) discriminator. It is not a key field.
How does Entity Framework determine what and what Type the discriminator field should be, and is it always the same, i.e. nvarchar? Is the discriminator at all accessible outside the database i.e. from LINQ to Entity?
Discriminator column is by default nvarchar because it stores names of your classes to differ between types - that is the whole point of this column: to allow EF knowing what class instance from your inheritance hierarchy it should create when it loads record from the database.
Discriminator column is not accessible by linq-to-entities. It is only used to map record to correct type.
Related
I've been looking at various Code First examples of TPT (Table Per Type) in Entity Framework.
I have an abstract base class with 4 concrete implementations, all of which share the exact same interface. These are being stored using EF in a single table named after the abstract base class.
What I wish to do is use the EF Discriminator column, but without using the automatic table creation in Code First, instead adding the configuration and mappings manually. Does anyone know if this would be possible and if so, what the type of the Discriminator column is (name, type, length, nullable, etc.) so I can create one manually?
Many thanks.
I have very big table in my Database and a can't modify it.
So i have BaseEntity type for table.
I have several children (entity1, entity2) and i'd like to map each type to same column ("Date") and name properties differently.
Surely i can't move all same column properties to base type cause there is about 100 columns in my super table (it's not my design i've jst need to map it)
So i have 0019 error and is there any way to solve it or EF not for me?
No. TPH requires that each property defined in derived entity is exclusive for that entity (no other entity can map to the same column). This targets more general rule in EF - each column can be mapped only once. So if you need to use some column in more entities it must be defined in parent and must have same name in all child entities.
I have a legacy database that has a table called Address. Now two other tables can have address information assigned to it. To determine which table it came from, there is a SourceID field. If the SourceID is 1 then it is associated with the first table, if it is 2, it is address information for the second table.
This legacy database doesn't have any foreign key constraints defined on the database, and it cannot be added.
I am wondering if I use Entity Framework to create a model that will have this association. Where table 1 can have an entity that has a navigation to address information (with the condition that the SourceID =1) and same with the second table.
I have tried created a conditional mapping and have it set "When SourceID = 1" I also removed the mapping from the column mapping as the column can only be mapped once. When I try to compile, I get the following error:
Error 3004: Problem in mapping fragments starting at line 683: No mapping specified for properties Address.SourceID in Set Addresses. An Entity with Key (PK) will not round-trip when: Entity is type [Model.Address]
Thanks for your help!
Don't use conditional mapping. Map your address to the entity without SourceID property and create two derived entities from the address entity. Use SourceID as discriminator (TPH inheritance - it works same as conditional mapping but you have multiple entities with different discriminator value). Relate your first and second entity to correct address sub entity.
When we have two entities in EFv4 EDM diagram and only one table for both in the database (for instance, having table Documents and entities Invoice and Qoute), table Documents having documentTypeId column as a discriminator and set this column as a discriminator in the EDM (in Table mappings), how do we read the value of this property in our code?
We cannot assign values to it because EF does it for us under the hood (based on what we entered in Table mappings for condition) but somehow I don't get it why we are also not allowed to read it.
Imo this property is already mapped so you can't map it again. It is used to determine type of materialized entity. Why do you need such column. Usually it is enough to use is operator like:
var document = context.Documents.GetById(id);
if (document is Invoice)
{
...
}
If you only need to select subtypes you can use OfType extension method like:
var invoices = context.Documents.OfType<Invoice>().ToList();
You also don't need to set this value when adding new entity because you are adding subtype - Invoice or Quote.
Edit:
As I understand from your comment you don't need this information in query. In such case you don't need to map it. Simply use partial class of your entity and add custom property which will return your string. Sound like stupid solution but actually it would be the easiest one.
Discriminator column should be part of mapping metadata so in case of T4 template generating your entities, it could be possible to update the template so it generate such property for you.
You may want to use a single-table inheritance hierarchy, as described here.
That way, you could have an abstract Document class that includes a DocumentTypeId column. Invoices and Quotes would extend this class, but specify certain DocumentTypeId filters. However, because the original class has a DocumentTypeId column, they would each have that column as well.
Another advantage to this approach is that you could create utility methods that can act on any Document, and you could pass any Invoice or Quote to these methods.
In trying to normalize a database schema and mapping it in Entity Framework, I've found that there might end up being a bunch of lookup tables. They would end up only containing key and value pairs. I'd like to consolidate them into one table that basically has two columns "Key" and "Value". For example, I'd like to be able to get Addresses.AddressType and Person.Gender to both point to the same table, but ensure that the navigation properties only return the rows applicable to the appropriate entity.
EDIT: Oops. I just realized that I left this paragraph out:
It seems like a TPH type of problem, but all of the reading I've done indicates that you start with fields in the parent entity and migrate fields over to the inherited children. I don't have any fields to move here because there would generally only be two.
There are a lot of domain-specific key-value pairs need to be represented. Some of them will change from time to time, others will not. Rather than pick and choose I want to just make everything editable. Due to the number of these kinds of properties that are going to be used, I'd rather not have to maintain a list enums that require a recompile, or end up with lots of lookup tables. So, I thought that this might be a solution.
Is there a way to represent this kind of structure in EF4? Or, am I barking up the wrong tree?
EDIT: I guess another option would be to build the table structure I want at the database level and then write views on top of that and surface those as EF entities. It just means any maintenance needs to be done at multiple levels. Does that sound more, or less desireable than a pure EF solution?
Table per hiearchy demands that you have one parent entity which is used as base class for child entities. All entities are mapped to the same table and there is special discriminator column to differ type of entity stored in database record. You can generally use it even if your child entities do not define any new properties. You will also have to define primary key for your table otherwise it will be handled as readonly entity in EF. So your table can look like:
CREATE TABLE KeyValuePairs
(
Id INT NOT NULL IDENTITY(1,1),
Key VARCHAR(50) NOT NULL,
Value NVARCHAR(255) NOT NULL,
Discriminator VARCHAR(10) NOT NULL,
Timestamp Timestamp NOT NULL
)
You will define your top level KeyValuePair entity with properties Id, Key, Value and Timestamp (set as concurrency mode fixed). Discriminator column will be used for inheritance mapping.
Be aware that EF mapping is static. If you define AddressType and Gender entities you will be able to use them but you will not be able to dynamically define new type like PhoneType. This will always require modifying your EF model, recompiling and redeploying your application.
From OOP perspective it would be nicer to not model this as object hiearchy and instead use conditional mapping of multiple unrelated entities to the same table. Unfortunatelly even EF supports conditional mapping I have never been able to map two entities to the same table yet.