Здравствуйте, adontz, Вы писали:
A>>>Да нет, дело не в том что удобнее, а в том что правильнее. VD>>Супер. Новое инженерно-научный постулат "правильнее". VD>>Можно задать критерии правильности в общем случае?
A>Влад, если нечего сказать по существу, то лучше вообще не писать,
О, мудрая мысль. Но тебе придется сломать обе раку чтобы избежать искушения ответить мне .
Вот этот ответ, например, не имеет никакого отношения к вопросу (да вообще ни к чему).
Мой тебе совет. Прежде чем советовать окружающим о том про что им писать, или высказывать им свое мнение о том, что их слова не обоснованны, тебе лично нужно научиться обосновывать свои слова и смотреть на них критически.
A>ведь разговаривать про клиентский кеш ты недавно отказался.
И что? Он не имеет отношения к делу. В теме речь шла о доступе к данным (БД).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tom, Вы писали:
VD>>Запросы не панацея — способ обработки данных. Его прекрасно можно использовать для обработки данных вместо дурацкого запаковывания всего и все в объекты и попыток использовать ООП для обработки данных. Tom>Я чего то не понимаю где я писал что буду использовать ООП?
Как только тема переехала в Философию, сразу же подключились маньяки ОРМ-щики. Мы тут получаемся между двух огней. С одной твой лагерь который предлагает все на транзакте делать, с другой ОРМ-щики. Иногда путаешь кому что отвечать.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tom, Вы писали:
Tom>Конечно можно использовать ORM WAY но хрен редьки не слаще, а только геморней.
А это ты Адонцу и Кибераксу объясни. Точнее они тебе сейчас объяснят .
Они просто увлеклись покусыванием нас и не поняли, что ты с нами дискутируешь не с их позиций.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
G>Даже апдейты не нужны.
Не понял, в задаче чётко сказано Заказы не выполненые по любой причине в течении дня перевестись в статус задержанные.
У тебя вижу только селект.
G>>>Если будет Linq или EF провайдер с поддержкой DML, то буду использовать только его. Tom>>Пример можно? И где вообще ты нашёл про поддержку DML в EF 2? G>Меня в EF интересует не eSQL и Object Services, а модель провайдеров и edm. G>Сейчас в EF есть AST для представления запросов, в том числе числе insert\update\delete.
Какой нафик AST и причём он к EF? И где ты взял что они будут сильно менять edm?
Максимум — переделают работу с relation-ами.
G>Но нету способов сформировать ast для DML, они формируются внутри при вызове SaveChanges в контексте. G>Я сначала хотел написать методы-расширения для DML, но уперся в убогость самого средства описания модели данных — edm. G>Ко второй версии EF обещают edm поправить, и если у них не будет провайдера с DML, то напишу свой.
DML — я нет и не будет, и здаётся мне что задача написать такой провайдер сама по себе не простая.
Ибо даже на сегодняшний день ни у одного комерчвеского linq решения она не реализована.
G>Выше.
Выше вижу селект. задача была обновить state.
Здравствуйте, Tom, Вы писали:
Tom>Можем перейти к примерам (оставим розового слоника в покое ). Вот допустим выполняешь ты запрос: Tom>update order set delayed = true where OrderDate < '...' Tom>По твоему подобный запрос не реализует часть бизнес логики?
Это именно запрос реализующий часть бизнес-логики.
И что?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Tom, Вы писали:
Tom>>Конечно можно использовать ORM WAY но хрен редьки не слаще, а только геморней.
VD>А это ты Адонцу и Кибераксу объясни. Точнее они тебе сейчас объяснят . VD>Они просто увлеклись покусыванием нас и не поняли, что ты с нами дискутируешь не с их позиций.
ну моя позиция чёткая — ORM зло. Максимум — это мапинг. остальное средствами БД. Тоесть коллекции и работа в коде с relation-ами идут в лес.
VD>Как только тема переехала в Философию, сразу же подключились маньяки ОРМ-щики. Мы тут получаемся между двух огней. С одной твой лагерь который предлагает все на транзакте делать, с другой ОРМ-щики. Иногда путаешь кому что отвечать.
Мне Ромина позиция вообще не понятна если честно. Он же со всеми не согласен (c)
VD>Это именно запрос реализующий часть бизнес-логики. VD>И что?
То, что часть логики всегда будет реализована с использованием запросов БД.
И это не вселенское зло а нормальная ситуация.
И в этом случае бизнес логика размазывается не только по слоям но и по компонентам деплоймента.
И это тоже не зло а нормальная ситуация.
Здравствуйте, gandjustas, Вы писали:
G>Сейчас в EF есть AST для представления запросов, в том числе числе insert\update\delete.
Как понимать выделенное?
G>Я сначала хотел написать методы-расширения для DML, но уперся в убогость самого средства описания модели данных — edm. G>Ко второй версии EF обещают edm поправить, и если у них не будет провайдера с DML, то напишу свой.
edm тут ровным счетом не причем. Проблема в том, что DML должен поддерживать массовые операции (типа "insert int x select ..."). Так вот проблема в том, что в linq-запросах на выборку теряется часть метаинформации нежной для связи запроса на выборку с запросом на вставку или обновление. Если будет собственный провайдер, то проблема будет решена. В прочем, возможно с небольшими хаками можно реализовать все и для существующих провадеров.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tom, Вы писали:
G>>Даже апдейты не нужны. Tom>Не понял, в задаче чётко сказано Заказы не выполненые по любой причине в течении дня перевестись в статус задержанные.
Флаг "задержинный" в базе — нарушение нормальзации, без веских причин я такого делать не буду.
Tom>У тебя вижу только селект.
Это задержанные заказы, что с ними дальше делать зависит от usecase.
Например можно взять всех менеджеров заказов и отправить им уведомление об их неправльной половой ориентации.
var managers = (from o in delayedOrders
select manager).Distinct();
foreach(var tuple in managers.Select(m => new {m.Name, m.Email}))
{
_notificationService.SendNotification(tuple.Email, tuple.Name, ...);
}
Причем запрос к базе будет только один.
G>>>>Если будет Linq или EF провайдер с поддержкой DML, то буду использовать только его. Tom>>>Пример можно? И где вообще ты нашёл про поддержку DML в EF 2? G>>Меня в EF интересует не eSQL и Object Services, а модель провайдеров и edm. G>>Сейчас в EF есть AST для представления запросов, в том числе числе insert\update\delete. Tom>Какой нафик AST и причём он к EF? И где ты взял что они будут сильно менять edm? Tom>Максимум — переделают работу с relation-ами.
Сильно и не надо, некоторых мелких изменений будет вполне достаточно.
G>>Но нету способов сформировать ast для DML, они формируются внутри при вызове SaveChanges в контексте. G>>Я сначала хотел написать методы-расширения для DML, но уперся в убогость самого средства описания модели данных — edm. G>>Ко второй версии EF обещают edm поправить, и если у них не будет провайдера с DML, то напишу свой. Tom>DML — я нет и не будет, и здаётся мне что задача написать такой провайдер сама по себе не простая.
Распарсить expression tree и и сформировать dbexpression tree задача конечно не простая, но решаемая? При том что основная сложность — построение where выражений с подзапросами уже реализована.
Tom>Ибо даже на сегодняшний день ни у одного комерчвеского linq решения она не реализована.
ну это только их проблемы.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, IT, Вы писали:
IT>>>>Ну так в чём тогда проблема? Объективная реальность C>>>Хочется чтоб всё быстро работало IT>>Сделай чтоб работало быстро C>Дык уже. С помощью идеологически неправильного антисоветского ORM
А не стремно это все ? Не даром люди 20 лет в оракле пилят consistency, security, и тп. А ты тут пришел со своим кешом объектов и всех зарулил. Ты бы видел их баглист ... Я даже думать не хочу, сколько там вылезет тараканов если прижать эту распределенную репликацию кешей серьезными тестами, с отказами каналов и тд и тп. Скорее всего речь идет о том, что конкретные клиенты уже приучены к "безопасным сценариям" и своим каналам и знают когда нужно "выйти и снова зайти"
Здравствуйте, Tom, Вы писали:
G>>Даже апдейты не нужны. Tom>Не понял, в задаче чётко сказано Заказы не выполненые по любой причине в течении дня перевестись в статус задержанные. Tom>У тебя вижу только селект.
Я бы тоже не делал полей для таких вещей, а вычислял бы все динамически или сделал бы индексированное представление для такого правила.
Но это уже обсуждение бизрес-логики.
Если наплевать на правильность постановки задачи, то даже сегодня можно было бы написать что-то типа:
var delayedOrders = from o in orders
where o.OrderDate < xxx
select o;
delayedOrders.Update(o => o.delayed, true);
// delayedOrders.Update(o => Set(o.delayed, true));
Все это будет преобразовано во время выполнения в update который привел ты.
Хорошим решением было бы сделать так:
var delayedOrders = from o in orders
where o.OrderDate < xxx
select o;
delayedOrders.Update(o => o.delayed = true);
Но деревья выражений не поддерживают присвоений.
Кстати, в Nemerle это можно было бы эмулировать. Более того в Nemerle можно и синтаксис прикрутить. Тогда можно будет писать так:
from o in orders
where o.OrderDate < xxx
update o.delayed = true
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tom, Вы писали:
VD>>Это именно запрос реализующий часть бизнес-логики. VD>>И что?
Tom>То, что часть логики всегда будет реализована с использованием запросов БД.
Дык с тобой никто и не спорит. С тобой спорят о том где этим запросам лежать и на чем написаны.
Tom>И в этом случае бизнес логика размазывается не только по слоям но и по компонентам деплоймента.
А вот это утверждение не верно. Такие запросы все можно положить в модуль бизнеслогики написанный на одном языке.
Tom>И это тоже не зло а нормальная ситуация.
Размазывание — это по любому проблема. (в терминах зла и добра я разговаривать не хочу)
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, gandjustas, Вы писали:
G>>Сейчас в EF есть AST для представления запросов, в том числе числе insert\update\delete.
VD>Как понимать выделенное?
См System.Data.Common.CommandTrees в сборке System.Data.Entity в частности DbUpdateCommandTree, DbInsertCommandTree, DbDeleteCommandTree.
Для всех написано что представляет из себя single-row operation, но это уже на совести генератора SQLя в провайдере к конкретной БД.
G>>Я сначала хотел написать методы-расширения для DML, но уперся в убогость самого средства описания модели данных — edm. G>>Ко второй версии EF обещают edm поправить, и если у них не будет провайдера с DML, то напишу свой.
VD>edm тут ровным счетом не причем.
Причем, так как вышеупоомянутые классы опираются на edm.
Если писать все с нуля, то можно и без edm обойтись, и придумать свой способ описания метаданных.
VD>Проблема в том, что DML должен поддерживать массовые операции (типа "insert int x select ..."). Так вот проблема в том, что в linq-запросах на выборку теряется часть метаинформации нежной для связи запроса на выборку с запросом на вставку или обновление. Если будет собственный провайдер, то проблема будет решена. В прочем, возможно с небольшими хаками можно реализовать все и для существующих провадеров.
Запросы вида insert ... select .. дейсвтительно не поддерживаются никак, короче дождусь второй версии EF, там буду думать.
Здравствуйте, SleepyDrago, Вы писали:
C>>Дык уже. С помощью идеологически неправильного антисоветского ORM SD>А не стремно это все ? Не даром люди 20 лет в оракле пилят consistency, security, и тп. А ты тут пришел со своим кешом объектов и всех зарулил. Ты бы видел их баглист ...
А кто говорит, что у меня нет consistency и security? Кстати, предыдущая итерация софта использовала прямое соединение с Оракулом и row-level security. С каким же удовольствием мы его прибили....
SD>Я даже думать не хочу, сколько там вылезет тараканов если прижать эту распределенную репликацию кешей серьезными тестами, с отказами каналов и тд и тп.
Как раз одной из причин использования моего кэша является очень низкое качество каналов. Мне даже пришлось делать свой протокол RPC, так как ни один из существующих не давал достаточной надёжности.
SD>Скорее всего речь идет о том, что конкретные клиенты уже приучены к "безопасным сценариям" и своим каналам и знают когда нужно "выйти и снова зайти"
Нет.
). Вот допустим выполняешь ты запрос:
Скорее всего речь идет о том, что конкретные клиенты уже приучены к "безопасным сценариям" и своим каналам и знают когда нужно "выйти и снова зайти" 
