Проблема с повторяющимся именем поля во вложенном многопозиционном запросе Dapper - PullRequest
Новая
       2

Проблема с повторяющимся именем поля во вложенном многопозиционном запросе Dapper

5 голосов
/ 14 сентября 2011

Я столкнулся с проблемой при попытке сделать многократное отображение с помощью Dapper для запросов на нумерацию страниц.

Поскольку я использую вложенный запрос в этом сценарии разбиения на страницы, во вложенном запросе есть несколько таблиця должен присоединиться, чтобы получить мои многоотображенные данные, но некоторые из этих таблиц будут иметь общие поля с тем же именем, которое вы можете увидеть в моем примере запроса ниже (например, id, displayname и 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";

В приведенном выше примере вы можете видеть, что во вложенном запросе будут проблемы с полями id (появляются в таблице posts, оба присоединения таблицы users иtopics присоединение к таблице), а также displayname и email (присутствуют в обоих users объединениях таблиц).

Единственный обходной путь, о котором я до сих пор думал, заключается в приведении каждого из этих «проблем»Поля под другим именем, но это влечет за собой очень грязный процесс создания фиктивных свойств в затронутых моделях, так что мультимаппирование может отображаться в них и редактировать «реальные» свойства в моих моделяхтакже проверить фиктивное свойство для значения, если действительное значение не было установлено.

Кроме того, в приведенном выше сценарии мне пришлось бы создать x фиктивных свойств, где x - это количество соединений, которые я могу иметь наодна и та же таблица в запросе (в этом примере 2 объединения в одной и той же таблице Users, поэтому требуются 2 фиктивных свойства с уникальным именем только для целей отображения Dapper).

Это, очевидно, не идеально, и я уверен, что будет иметьпостучите в проблемах и больше беспорядка, поскольку я создал больше этих многоуровневых запросов разбиения на страницы.

Я надеюсь, что есть хорошее, чистое решение этой проблемы?

1 Ответ

1 голос
/ 15 сентября 2011

Есть 2 варианта, которые я могу придумать:

вариант 1 : присоединиться к расширенным свойствам вне вложенного запроса: 

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

опция 2 : расширить SqlBuilder для обработки псевдонимов столбцов: 

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

Затем определить макрос псевдонимов для запроса и кэширования списка столбцов из БД, используя INFORMATION_SCHEMA.COLUMNS и просто добавьте строку 'column as column_t1` для каждого столбца.

Unalias может сделать обратное довольно просто.

...