Коллеги, добрый день!

Пытаюсь разобраться, есть ли в linq2db поддежка сабжа (SELECT — FOR Clause (Transact-SQL))? Если есть, как её использовать? Если нет, возможно ли её прикрутить, не меняя код библиотеки, снаружи?

не проще сформировать хмл на клиенте?

Здравствуйте, torvic, Вы писали:

T>не проще сформировать хмл на клиенте?

Есть ситуации, когда приходится писать select ... for xml. Например, вот: ListAGG in SQLSERVER. Версия SQL Server — 2016, STRING_AGG нет.

Здравствуйте, Петрухин Эдуард, Вы писали:

ПЭ>Коллеги, добрый день!

ПЭ>Пытаюсь разобраться, есть ли в linq2db поддежка сабжа (SELECT — FOR Clause (Transact-SQL))? Если есть, как её использовать? Если нет, возможно ли её прикрутить, не меняя код библиотеки, снаружи?

Сгенерировать такой код не проблема. Только не понятно во что здесь мапить.

Здравствуйте, IT, Вы писали:

IT>Сгенерировать такой код не проблема. Только не понятно во что здесь мапить.

Не совсем понял

Только не понятно во что здесь мапить.

?
Имелось ввиду «в какой тип»? У select ... for json тип результата — nvarchar(max), у select ... for xml — тоже nvarchar(max), если не задана директива «TYPE» (если задана — xml, type-directive-in-for-xml-queries.

Сигнатура, как я предполагаю, должна быть какая-то такая:

string SelectForXml<T>(this IQueryable<T> source, string mode)

Здравствуйте, Петрухин Эдуард, Вы писали:

ПЭ>Сигнатура, как я предполагаю, должна быть какая-то такая:

Такого нет, нужно делать.

Здравствуйте, IT, Вы писали:

IT>Такого нет, нужно делать.


Можешь задать направление — какие изменения и в каких местах нужно будет делать? Если будет время и если осилю — сделаю pull-request.
А нет ли чего-нибудь похожего (в смысле, функции, которая принимает на вход IQueryable и возвращающей скаляр), чтобы можно было подсмотреть?

Здравствуйте, Петрухин Эдуард, Вы писали:

ПЭ> Можешь задать направление — какие изменения и в каких местах нужно будет делать? Если будет время и если осилю — сделаю pull-request.

Сложно сказать. Для начала нужно навести порядок с алиасами в финальном SELECT. Иначе будет генерироваться шо попало. Потом по идее нужно финальную проекцию другую генерировать. В общем, смысла во всём этом FOR XML мало. Проще натравить какой-нибудь ObjectToXml и получить нужный XML на клиенте. Так же как и JSON.

ПЭ> А нет ли чего-нибудь похожего (в смысле, функции, которая принимает на вход IQueryable и возвращающей скаляр), чтобы можно было подсмотреть?

Нету

Здравствуйте, Петрухин Эдуард, Вы писали:

ПЭ>Коллеги, добрый день!

ПЭ>Пытаюсь разобраться, есть ли в linq2db поддежка сабжа (SELECT — FOR Clause (Transact-SQL))? Если есть, как её использовать? Если нет, возможно ли её прикрутить, не меняя код библиотеки, снаружи?

Какие бенефиты вы ожидаете? Я пока их не вижу. Точнее хотелось бы понять реальный Use case.

Здравствуйте, Danchik, Вы писали:

D>Какие бенефиты вы ожидаете? Я пока их не вижу. Точнее хотелось бы понять реальный Use case.

Да, наверное сразу надо было use case озвучить. По факту, сам по себе select ... for xml не нужен.
Есть проект (SQL Server 2016), в котором хочется внедрить linq2db для решения проблем с хранимками, запросами в строковых константах и ручным маппингом. Во многих запросах используется для конкатенации строк через разделитель используется select for xml (вот как здесь, например). Переход на SQL Server 2017 пока не предвидется, поэтому использовать STRING_AGG не получается.

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

Здравствуйте, Петрухин Эдуард, Вы писали:

ПЭ>Здравствуйте, Danchik, Вы писали:

D>>Какие бенефиты вы ожидаете? Я пока их не вижу. Точнее хотелось бы понять реальный Use case.

ПЭ>Да, наверное сразу надо было use case озвучить. По факту, сам по себе select ... for xml не нужен.
ПЭ>Есть проект (SQL Server 2016), в котором хочется внедрить linq2db для решения проблем с хранимками, запросами в строковых константах и ручным маппингом. Во многих запросах используется для конкатенации строк через разделитель используется select for xml (вот как здесь, например). Переход на SQL Server 2017 пока не предвидется, поэтому использовать STRING_AGG не получается.

ПЭ>Пока, по результатам общения, кажется, что проще будет сделать свою агрегатную функцию. Есть только опасения, что работать она будет не шибко быстро.

Да не все так просто. Я в таких случаях просто пишу методы заглушки и смотрю подходит ли мне API.
Потом можно думать писать ли расширения.

Здравствуйте, Петрухин Эдуард, Вы писали:

ПЭ>Пока, по результатам общения, кажется, что проще будет сделать свою агрегатную функцию. Есть только опасения, что работать она будет не шибко быстро.
Стесняюсь спросить — а что вам мешает в таких экзотических случаях проагрегироваться на клиенте?
Ведь внутри сервера ничего особенно чудесного не происходит — объём чтения и промежуточных результатов там точно такой же, как и без for xml.

Здравствуйте, Sinclair, Вы писали:

S>Стесняюсь спросить — а что вам мешает в таких экзотических случаях проагрегироваться на клиенте?
Немножко задержался с ответом .

S>Ведь внутри сервера ничего особенно чудесного не происходит — объём чтения и промежуточных результатов там точно такой же, как и без for xml.
Хотелось бы портировать код с хранимок на linq2db по возможности один в один. Например, при работе над задачей, в рамках которой пришлось бы изменить хранимку, вместо этого сначала портировать хранимку на linq2db, а после внести изменения, необходимые для решения задачи. При этом не хотелось бы кардинально менять логику запроса (портирование на linq2db — само по себе значительное изменение).
Таким образом, постепенно можно было бы портировать основную часть хранимок на linq2db. К сожалению, ресурсов на то чтобы заниматься портированием как отдельной задачей нет.