L'EntitySplitting : plus compliqué qu'il n'y parait
L'EntitySplitting permet de mapper une entité sur plusieurs tables (cf mon article sur EDM).
Cependant, il y a un cas très surprenant.
Imaginons une table Employees : Id (PK), LastName, FirstName et une table Consultants : Id (PK et FK vers Employees.Id).
Imaginons qu’on développe une application pour les consultants et uniquement pour eux, il serait intéressant de ne définir qu’une seule entité Consultant mappée à la fois sur la table Employees et sur la table Consultants.
Cependant, là, surprise !
Context.Consultants retourne tous les employés (y compris les non-consultants).
Et en regardant la requête SQL générée, la table Consultants est absente du SELECT.
Ceci est dû à une optimisation qui consiste à dire que vu qu’on a déjà récupéré l’Id via la table Employees, on peut s’épargner le INNER JOIN. Après en avoir discuté avec l’ADO .Net Team, cela est normal, c’est le comportement attendu (mais pas par moi).
J’ai alors tenté de mapper l’entité Consultant sur la table Consultants en premier puis sur la table Employees mais le résultat est le même.
Donc dans ce cas, il faudra utiliser de l'héritage (en l'occurence du TPT).
Maintenant, prenons le cas suivant : EntitySplitting sur deux tables avec seulement une colonne PK.
Dans ce cas, on récupèrera le résultat de la première table mappée.
En revanche, pas de soucis avec l’INSERT qui insère bien dans les deux tables.
J’ai fait une demande pour que cela change dans la V2 mais inutile de vous dire que cela n’évoluera pas avec le SP1 dont la sortie est imminente.
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
