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

G>Давайте сделаем наоборот, напишите такой Upddate statement (без всякой императивщины), который нельзя выразить в чистом функциональном стиле на любом языке

С простыми update-ами как здесь

Автор: gandjustas
Дата: 31.03.09

понятно.
Но как на C# будет выглядеть, например

UPDATE Person
SET Age = DATEDIFF(y, GETDATE(), BirthInfo.birthDate)
FROM Person
JOIN BirthInfo ON BirthInfo.PersonID = Person.ID

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

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

G>>Давайте сделаем наоборот, напишите такой Upddate statement (без всякой императивщины), который нельзя выразить в чистом функциональном стиле на любом языке

L>С простыми update-ами как здесь

Автор: gandjustas
Дата: 31.03.09

понятно.
L>Но как на C# будет выглядеть, например
L>

L>UPDATE Person
L>SET Age = DATEDIFF(y, GETDATE(), BirthInfo.birthDate)
L>FROM Person
L>JOIN BirthInfo ON BirthInfo.PersonID = Person.ID
L>

Для update from можно придумать метод update c другой сигнатурой или использовать подзапросы для решения таких задач.

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

L>>А зачем?
G>Затем что цель именно в этом. Не надо выражать операции какого-либо языка в SQL, надо выразить SQL DML в некоторых конструкциях языка.

Цель — по заданному SQL генерить конструкции языка? По моему, ровно наоборот :-)

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

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

L>>>А зачем?
G>>Затем что цель именно в этом. Не надо выражать операции какого-либо языка в SQL, надо выразить SQL DML в некоторых конструкциях языка.

L>Цель — по заданному SQL генерить конструкции языка? По моему, ровно наоборот

Еще раз. Цель — выразить SQL DML в конструкциях языка, по научному — найти сьюрьективное отображение некоторого подмножества языка в SQL DML.

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

G>Еще раз. Цель — выразить SQL DML в конструкциях языка, по научному — найти сьюрьективное отображение некоторого подмножества языка в SQL DML.

Зачем вообще говорить о сюрьективном отображении, если даже DML-и разные для разных БД?
Если же нам достаточно инъекции, то DML не надо выражать в конструкциях языка, а надо получать его из этих самых конструкций.
Ч.т.д.

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

А что тут такого военного? Смотри, всё, что нам нужно — это коллекция записей {Id, Age}.
Получать ее Linq уже умеет, не так ли?
Теперь осталось добавить в него update statement, куда можно скормить эту коллекцию и объяснить "для каждого Person с заданным Id установи Age в переданный Age".
Инфраструктура должна уметь отличать ситуацию, когда источник — соответствующий IQueryable, который можно вычислить на стороне сервера, от ситуации, когда это, к примеру, List<Tuple<...>>, и нужно породить батч одиночных update Person.

Это заодно даёт ответ на вопрос "что делать, если преобразование невыразимо в SQL".
Ну там, MD5 пытаемся посчитать от фамилии, или еще что. Точно так же, как сейчас, Linq будет выкидывать исключение о том, что не удалось построить SQL запрос, и программисту придется принудительно материализовать промежуточный запрос, выполнить преобразование, и отдать обратно результат (в виде батча апдейтов одиночных записей).
Целостность будет гарантироваться тем, что мы выполняем всё в рамках одной транзакции.
Это не так здорово, как выполнить всё полностью на сервере, но всё еще, имхо, лучше, чем подход с датасетами.

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

S>А что тут такого военного? Смотри, всё, что нам нужно — это коллекция записей {Id, Age}.
S>Получать ее Linq уже умеет, не так ли?
S>Теперь осталось добавить в него update statement, куда можно скормить эту коллекцию и объяснить "для каждого Person с заданным Id установи Age в переданный Age".

Меня интересует как может выглядеть подобный зарос в синтаксисе C#, а не принцип.
Все варианты, которые мне приходят в голову, мягко говоря не очень удобные.

Здравствуйте, Lloyd, Вы писали:
L>Меня интересует как может выглядеть подобный зарос в синтаксисе C#, а не принцип.
В гипотетическом синтаксисе?

from .... 
... 
update ... set

L>Все варианты, которые мне приходят в голову, мягко говоря не очень удобные.
Ну, пока что шарп ухитрился остаться очень близким к оригинальному SQL. Варианты сиквела (с точностью до порядка clause) меня вполне устраивают.

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

L>>Меня интересует как может выглядеть подобный зарос в синтаксисе C#, а не принцип.
S>В гипотетическом синтаксисе?
S>

S>from .... 
S>... 
S>update ... set 
S>

Нет, в синтаксисе C#

L>>Все варианты, которые мне приходят в голову, мягко говоря не очень удобные.
S>Ну, пока что шарп ухитрился остаться очень близким к оригинальному SQL. Варианты сиквела (с точностью до порядка clause) меня вполне устраивают.

LINQ оказался пожалуй даже лучше, чем SQL. Очень удобно то, что можно манипулировать самим запросом без его непосредственного исполнения, добавлять условия фильтрации, ограничивать получаемые поля и т.д.
Как такой же гибкости можно добиться и в update-ах мне не совсем понятно. В частности, было бы удобно достраивать список обновляемых в update-е полей в зависимости от каких-то условий, например, прав пользователя. Что-то типа реляционной алгебры, но не для select-а, а для update-а.

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

G>Здравствуйте, Sergey T., Вы писали:

ST>>Я сразу извиняюсь, что а) отвечаю вам, потому б) что возможно кого-то повторю, ибо до конца не дочитал, не вытерпел
ST>>Итак, основной спор помниться был о массовых апдейтах, и почему в ЛИНК нет синтаксиса для "массовых апдейтов", и почему скрипт транзакции лучше, чем UoW.
ST>>Я полностью согласен с поклонниками скриптов транзакций, но они забывают (забывали, по крайней мере, на первой странице) одну простую вещь: для того, чтобы скрипт транзакций отработал, все объекты из контекста нужно сохранить в базу данных.
G>При таком подходе у нас просто не будет объектов в контексте. Вообще не будет.

ST>>Далее, отказавшись от Unit of Work в линке мы для сохранения объектов вынуждены использовать такой же кастрированный апдейт. Причем, сохранять каждый объект отдельно и в цикле, сами отслеживая его изменения. Чем не единица работы своими руками?
G>Отслеживание изменений — необходимость при работе с объектами. Если отказываемся от UoW то у нас и логика будет по-другом строиться.
G>Нам в принципе не нужны будут циклы, вся массовая обработка будет заключаться именно в выполнении запроса.

G>А уже на основе этой системы можно реализовать и UoW, только зачем...
Согласен с вами, однако в вашем посте ключевое слово "массовая". Если нет "массовой", а другими словами "однотипной" обработки множества объектов — нет апдейта, а есть апдейты.

Далее. Отслеживание изменений — это в принципе не необходимость, а средство оптимизации производительности. Контекст (Unit of Work) — в первую очередь, средство обеспечения правильного порядка операций записи (чтобы не вылететь по ограничениям и внешним ключам СУБД), в вторую очередь — средство оптимизации (чтобы не сохранять все, что загрузили), и уже в третью очередь — это удобство.

Я вообще конечно двумя руками "за" "типизированные апдейты" и трансляцию кода С# в SQL. Только вот для такой большой части типовых сценариев "прочитал из базы, передал клиенту (через сервис), дал поредактировать пользователю, залил обратно (через тот же сервис), залил в базу" не получится сделать выражение (expression) апдейта. А получится — в случае, если нет контекста — CUD запросы по числу объектов. Потом оно начнет тормозить на больших объемах, потом введется признак редактирования объекта, потом IsDirty перекочует во внешний объект — и здравствуй, контекст. Но суть в том, что это будут те же яйца, только в профиль, поскольку редактирование набора объектов пользователями — это явно не однотипная обработка, и здесь типизированный апдейт никак не применишь.

С другой стороны, код на C#, который при определенных условиях выполняется средствами СУБД — это здорово.

В дополнение хочу заметить, что задача ОРМ не только "подружить данные и объекты", но еще и подружить реляционную структуру данных с иерархической структурой объектов. Имея две таблицы Order и OrderItem, и имея два класса OrderItem и class Order { public Collection<OrderItem> Items {get;} ...}, в которые в основном превращаются данные такого рода.

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

ST>Я вообще конечно двумя руками "за" "типизированные апдейты" и трансляцию кода С# в SQL. Только вот для такой большой части типовых сценариев "прочитал из базы, передал клиенту (через сервис), дал поредактировать пользователю, залил обратно (через тот же сервис), залил в базу" не получится сделать выражение (expression) апдейта.
Почему не получится? Я препятствий не вижу.

ST>А получится — в случае, если нет контекста — CUD запросы по числу объектов.
По числу добавленных\измененных\удаленных объектов. Клиент вполне может передавать списки удаляемых\обновляемых\вставляемых объетов.
Кроме того чаще всего пользователь работает с одим объектом или одним списком объектов.

ST>Потом оно начнет тормозить на больших объемах, потом введется признак редактирования объекта, потом IsDirty перекочует во внешний объект — и здравствуй, контекст. Но суть в том, что это будут те же яйца, только в профиль, поскольку редактирование набора объектов пользователями — это явно не однотипная обработка, и здесь типизированный апдейт никак не применишь.
В таком случае и ORMы со всеми фичами мало чего дают.

ST>В дополнение хочу заметить, что задача ОРМ не только "подружить данные и объекты", но еще и подружить реляционную структуру данных с иерархической структурой объектов. Имея две таблицы Order и OrderItem, и имея два класса OrderItem и class Order { public Collection<OrderItem> Items {get;} ...}, в которые в основном превращаются данные такого рода.
Маппинг — ортогональная задача.

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

no4>А нельзя ли как-то это совместить? С одной стороны данные важны. С другой стороны, хотелось бы манипулировать более высокоуровневыми абстракциями чем Entities.

Нет. ООП был разработан для эмуляции объектов реального мира и подразумеваемых объектов в рамках памяти компьютера. Его модель не ложится на хранение данных на дисках и не предоставляет высокоуровневых средств манипуляции данными (рассчитана на императивную обработку).

no4>Например, сделать объектно-ориентированный язвк, чтобы он:
no4> * был декларативныой
no4> * поддерживал транзакции

Оба пункта противоречат императивной природе ООП.

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