c# - EF inheritance with table splitting -
i'm trying map 2 different ef models same table sharedtable, let call them entitya , entityb. made them both extend base entity called baseentity.
entitya defined sharedtable fields, entityb has fields in sharedtable , entitybtable.
modelbuilder.entity<baseentity>() .map<entitya>(m => m.requires("isentitya").hasvalue<bool>(true)) .map<entityb>(m => m.requires("isentitya").hasvalue<false>(true)); modelbuilder.configurations.add(new entitybmap()); modelbuilder.configurations.add(new entityamap()); modelbuilder.configurations.add(new baseentitymap());
the models this
public class baseentity { [required] public int id { get; set; } public int sharedtablefield1 { get; set; } } public class entitya : baseentity { public int sharedtablefield2 { get; set; } } public class entityb : baseentity { public int entitybtablefield1 { get; set; } }
the mappings are
public class baseentitymap : entitytypeconfiguration<baseentity> { public baseentitymap() { // primary key this.haskey(t => t.id); this.totable("sharedtable"); this.property(t => t.id).hascolumnname("id"); this.property(t => t.sharedtablefield1).hascolumnname("sharedtablefield1"); } } public class entityamap : entitytypeconfiguration<entitya> { public entityamap() { this.haskey(t => t.id); this.property(t => t.id).hascolumnname("id"); this.totable("sharedtable"); this.property(t => t.sharedtablefield2).hascolumnname("sharedtablefield2"); } } public class entitybmap : entitytypeconfiguration<entityb> { public entitybmap() { map(c => { haskey(t => t.id); property(t => t.id).hascolumnname("id"); c.properties(t => new { t.sharedtablefield2 }); c.totable("sharedtable"); }); map(c => { c.properties(t => new { t.entitybtablefield1 }); c.totable("entitybtable"); }); } }
the error says:
a first chance exception of type 'system.notsupportedexception' occurred in entityframework.dll
additional information: type 'entityb' cannot mapped defined because maps inherited properties types use entity splitting or form of inheritance. either choose different inheritance mapping strategy not map inherited properties, or change types in hierarchy map inherited properties , not use splitting.
any way around this?
the inheritance strategy you've chosen table per type (tpt).
you've got 3 types: 1 base type baseentity
, 2 derived types entitya
, entityb
. decided put them 3 separate tables. baseentity
properties of both entitya
, entityb
put in 1 table. entitya
, entityb
each have foreign key base properties in baseentity
table.
whether inheritance strategy best problem depends on whether query baseentities
... or 'entitya/
entityb` ... consider using table per concrete class (tpc)
the tpt inheritance strategy implies join every query entitya
... base class properties used. if you'd use tpc join not needed. however, tpc requires concat whenever ask 'baseentities` ... depends kind of queries inheritance strategy best needs.
if want stick strategy tpt, seems don't build model correctly.
- you don't want store
baseentity
objects on own. if you'd allow that, wouldn't inheritance, one-to-zero-or-one relation: everyentitya
belongs 1baseentity
, , everybaseentity
has 0 or 1 'entitya. not want: every
baseentityhas either one
entityaor 1 '
entityb, , every 'entitya
/entityb
has 1 'baseentity` - as don't want store
baseentity
objects, 'baseentity` class ought declared abstract, in given link tpt. - in class definitions of
entitya
enentityb
, don't mention foreign keybaseentity
table. again, see given link tpt
i think abstract base class , lack of foreign keys key information let entity framework know chose inheritance strategy tpt.
- in model building, mention table names , if needed column names. don't mention foreign keys
when built model this, entity framework created 3 tables tpt. fluent api nor attributes needed. though didn't mention foreign keys, entity framework knew needed polymorphic association. again see link tpt
by way, [required] on integers useful? if wanted to, couldn't give integers null value. didn't mean [key]? following entity framework code first conventions not necessary.
Comments
Post a Comment