Problème de duplication de nom de champ dans une requête de pagination Dapper imbriquée et multi-cartographique

Question

J'ai rencontré un problème en essayant de faire du multi-mapping avec Dapper, pour des requêtes de pagination.

Comme j'utilise une requête imbriquée dans ce scénario de pagination, il y a plusieurs tables dans la requête imbriquée que je dois joindre pour obtenir mes données multi-mappées, mais certaines de ces tables partageront des champs du même nom, comme vous pouvez le voir dans mon exemple de requête ci-dessous (par ex. id , displayname y email ):

q = @"select * from (select p.id, p.title, p.etc...,
u1.id, u1.displayname, u1.email,
u2.id, u2.displayname, u2.email,
t.id, t.name,
row_number() over (order by " + sort.ToPostSortSqlClause() + ") as rownum" +
" from posts p" +
" join users u1 on p.owneruserid = u1.id" +
" join users u2 on p.lastediteduserid = u2.id" +
" join topics t on p.topicid = t.id" +
") seq where seq.rownum between @pLower and @pUpper";

Dans l'exemple ci-dessus, vous pouvez voir qu'à l'intérieur de la requête imbriquée, il y aura des problèmes avec les champs id (figure dans le posts les deux users et les jointures de tables topics ), ainsi que displayname y email (apparaissent dans les deux users les jonctions de tables).

La seule solution à laquelle j'ai pensé jusqu'à présent consiste à attribuer un nom différent à chacun de ces champs "problématiques", mais cela implique un processus très compliqué de création de propriétés fictives dans les modèles concernés, afin que le multimapping puisse s'y appliquer, et de modification des propriétés "réelles" dans mes modèles afin de vérifier également la valeur de la propriété fictive si la valeur réelle n'a pas été définie.

De plus, dans le scénario ci-dessus, je devrais créer x propriétés fictives où x est le nombre de jointures que je peux avoir sur la même table dans une requête (dans cet exemple, 2 jointures sur la même table Utilisateurs, nécessitant donc 2 propriétés fictives nommées de manière unique juste pour les besoins du mapping Dapper).

Ce n'est évidemment pas l'idéal et je suis sûr qu'il y aurait des problèmes en cascade et plus de désordre au fur et à mesure que je créerais plus de ces requêtes de pagination multi-mappings.

J'espère qu'il existe une solution simple et efficace à ce problème ?

Answer 1

Je pense qu'il y a deux possibilités :

option 1 Les propriétés étendues peuvent être jointes à l'extérieur de la requête imbriquée :

select s.*, t1.*, t2.* from 
(
select s.*, ROW_NUMBER() OVER (order by somecol) AS RowNumber from Something s
) as X 
left join Table t1 on Id = x.SomeId
left join Table t2 on Id = x.SomeOtherId

---

option 2 : Prolonger SqlBuilder pour gérer l'aliasing des colonnes :

select s.*, /**unalias(Table,t1)**/, /**unalias(Table,t2)**/ from 
        (
        select s.*, /**alias(Table,t1)**/, /**alias(Table,t2)**/ ROW_NUMBER() OVER (order by somecol) AS RowNumber from Something s
        left join Table t1 on Id = x.SomeId
        left join Table t2 on Id = x.SomeOtherId
        ) as X 

Définissez ensuite la macro alias pour interroger et mettre en cache une liste de colonnes de la base de données à l'aide de INFORMATION_SCHEMA.COLUMNS et ajoutez simplement une chaîne "column as column_t1" pour chaque colonne.

Les Unalias permettent de faire l'inverse très simplement.