).
Просто у меня янус три дня глючил и не отправлял ответы. S>Второй раз отвечу что лучше по старинке: S>
S>(from o in orders where o.OrderDate < xxx select o).
S> Update(o => o.SetDelayed(true)).
S> Update(o => SetDiscount(o.discount + Consts.DelayDiscountRate)); // кстати чисто в теории такие методы вполне можно мапить на хранимые процедуры - вообще ляпота будет.
S>
S>Проще парсить expression tree. S>Да и в концепцию IQueryable лучше вписывается.
В принципе, да. Я не против . Всё равно в основе лежит Expr<Func<T, T>>.
Альтернативный подход построен на Expr<Action<T>>, и выковыривании изменений, примененных к объекту "по месту". (...UpdateAll(o=>{o.Name = "Vasya";})).
Этот подход ближе к помыслам ORM-щиков; мне он принципиально не нравится, т.к. позволяет скомпилировать код, меняющий состояние объектов вне контекста UpdateAll, что полностью противоречит идее явных апдейтов.
Впрочем, Wayward вроде придумал механику, которая позволяет совместить оба подхода в рамках достаточно худенького IUpdatable<T>. http://blogs.msdn.com/mattwar/archive/2009/01/22/building-a-linq-iqueryable-provider-part-xiii-iqtoolkit-v-0-13.aspx
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
А на вэйварда я даже подписан, заодно с Bart De Smet. Кcтати, не читали блог последнего? Крайне забавные темы проскальзывают. Из моих любимых — прикручиваем linq ко всему и осло.
Здравствуйте, Sinclair, Вы писали:
S>Смысл этого — в том, чтобы вовремя накладывать предикаты, а не размазывать эту логику по всем миллионам хранимок копи-пейстом.
Какая разница, размазывать логику или нет, если хранимки генерируются?
Вызвать IQueryable<T> SecurityCheck<T>(IQueryable<T> source) можно запросто забыть. Ничто тебя не обязывает к этому вызову. Права доступа должны быть уровнем ниже бизнес-логики, иначе будут постоянные проблемы.
Здравствуйте, Sinclair, Вы писали:
S>Вот представь, что "многие-ко-многим" — это авиарейсы между городами. Каждый город, естественно, оборудован огромным количеством подробностей. Но вот ты выводишь табличку, к примеру, рейсов конкретной авиакомпании. Зачем тебе "экземпляры" всех городов? Всё, что тебе нужно — это список вида {string Departure, string Destination}. Ну так ты его и получишь! S>Если тебе интересно получить граф типа "полное описание города -> список доступных пунктов назначения", то тебе и нужна коллекция структур вида {Сity city, IEnumerable<string> Destinations}. Зачем тебе опять полные экземпляры в правой части? S>Хотеть их — вредное занятие. А то, о чем я пишу, тривиально получается в линке. За что мы его и любим.
Антон, я уже привёл пример где было надо иметь полный граф. С авиарейсами разговор беспредметный, потому что не ясна задча — что делать с данными, как обрабатывать.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Sinclair, Вы писали:
S>>Смысл этого — в том, чтобы вовремя накладывать предикаты, а не размазывать эту логику по всем миллионам хранимок копи-пейстом.
A> Какая разница, размазывать логику или нет, если хранимки генерируются?
Так что, хранимки генерируются на ВСЕ возможные запросы? В хранимках страшная каша будет из бизнес-логики и деталей представления.
A> Вызвать IQueryable<T> SecurityCheck<T>(IQueryable<T> source) можно запросто забыть. Ничто тебя не обязывает к этому вызову.
Для этого существуют механизмы AOP как compile-time, так и runtime.
A>Права доступа должны быть уровнем ниже бизнес-логики, иначе будут постоянные проблемы.
Чушь повторенная несколько раз истиной не становится.
Здравствуйте, Sinclair, Вы писали:
A>>Влад, мы не реплицируем БД. в данном случае репликация — это костыль для твоей системы неспособной к локальному кешированию. S>Это как раз ОRM-системы неспособны к локальному кэшированию. Там кэш может быть исключительно глобальный, иначе ты мгновенно напорешься на рассогласование.
Это не правда, соответственно все твои выводы тоже не правильные.
S>А в linq-подходе, о котором говорит Влад, запросто можно (если нужно) кэшировать конкретный результат конкретного запроса.
И получать кучу несогласованных кешей, о чём я уже и говорил.
S>На практике, к примеру, работа с почтой через OWA жрет в разы меньше трафика, чем честная синхронизация Outlook. А это — именно то, о чем ты говоришь. Синхронизация притаскивает на клиента полную реплику базы, и она обязана постоянно бегать и рефрешить все изменившиеся объекты — а то вдруг война (пользователь ткнул в объект), а я без каски (он устарел).
Кто говорил о полной реплике? По-моему, я ясно дал понять, что неполная реплика вполне может быть целостной. И насчёт "войны", я опять таки говорил, что обновление кеша необходимо только при модификации объекта.
S>Причем по этому пути можно заходить достаточно далеко — если сделать протокол взаимодействия клиента и сервера более умным, чем плоский SQL/TDS. К примеру, для некоторых (только тех, которые нужны) видов запросов сервер может обучиться вычислять LastModifiedDate и сравнивать ее с датой, переданной клиентом в запросе. Ну, а дальше — традиционное 304 либо 200, смотря что нашлось. Это я не говорю про RFC3229, который позволяет обмениваться только "дельтами". S>И при должном развитии Linq в широком смысле слова (как интеграции запросов в язык) это всё можно делать в достаточно обобщенном виде. Как только мы включаем реляционную алгебру, мы опять получаем возможность прицепить "delta-predicate" к любому запросу, который содержит LastModifiedDate. Это не будет затенять основную бизнес-логику, потому что будет описано в совершенно ортогональном ей месте.
Антон, это всё очень интересно, но к практике отношения не имеет. Чтобы считать дельту надо иметь две версии ответа: старую и новую, для каждого клиента. Кешировать все ответы для всех клиентов? Нет, это не реально.
Более того, дело даже не в объёмах данных, а во времени отклика. Пустой запрос к серверу может отожрать секунду и интерфейс начнёт сильно тормозить, когда кто-то качает фильм через торент. А ещё, бывает, что соединение с сервером есть не всегда. Linq более или менее приемлем только для веб-сайтов и то ИМХО вызывает проблемы. Для клиент-серверных (и n-tier в целом) систем он неприемлем вообще.
Здравствуйте, Sinix, Вы писали: S>А на вэйварда я даже подписан, заодно с Bart De Smet. Кcтати, не читали блог последнего? Крайне забавные темы проскальзывают. Из моих любимых — прикручиваем linq ко всему и осло.
Спасибо, под
писался.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, adontz, Вы писали:
A> Какая разница, размазывать логику или нет, если хранимки генерируются?
1. Зачем заниматься генерацией ненужного кода?
2. Если даже код нужный, то почему не сделать генерацию прозрачной? Например, она может происходить в тот момент, когда запрос собран и происходит вызов .ToArray().
Пример хорошей генерации кода: IL->x86.
Пример плохой генерации кода: генерация сотен хранимок "просто так".
A> Вызвать IQueryable<T> SecurityCheck<T>(IQueryable<T> source) можно запросто забыть. A>Ничто тебя не обязывает к этому вызову. Права доступа должны быть уровнем ниже бизнес-логики, иначе будут постоянные проблемы.
Права доступа зачастую и есть часть бизнес-логики.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, adontz, Вы писали: A>Антон, я уже привёл пример где было надо иметь полный граф.
Нет, не привёл. Ты искусственно потребовал "собрать граф объектов" без малейшей мотивации того, для чего он тебе нужен.
Это проблема ментальной модели, и я с этой проблемой тесно знаком. Спроси ОРМ-программиста захрена он тащит в тонкого клиента полную географию США — он смотрит на тебя как на идиота и говорит "ну так мне же нужно показать список штатов в дроп-дауне". A>С авиарейсами разговор беспредметный, потому что не ясна задча — что делать с данными, как обрабатывать.
Правильно. Приведи предметный пример, который не сводится к задаче "хочу граф объектов и чтобы внутри обязательно были сцылки".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Это проблема ментальной модели, и я с этой проблемой тесно знаком. Спроси ОРМ-программиста захрена он тащит в тонкого клиента полную географию США — он смотрит на тебя как на идиота и говорит "ну так мне же нужно показать список штатов в дроп-дауне".
Это плохой ORM-программист. Нормальный программист просто вытащит список объектов типа State для заданной страны. В объекте State будет три поля "id", "name" и "abbreviation".
Здравствуйте, gandjustas, Вы писали:
A>> Какая разница, размазывать логику или нет, если хранимки генерируются? G>Так что, хранимки генерируются на ВСЕ возможные запросы? В хранимках страшная каша будет из бизнес-логики и деталей представления.
Ещё раз, я не считаю механизмы проверки прав доступа бизнес-логикой.
A>> Вызвать IQueryable<T> SecurityCheck<T>(IQueryable<T> source) можно запросто забыть. Ничто тебя не обязывает к этому вызову. G>Для этого существуют механизмы AOP как compile-time, так и runtime.
Ну атрибут забудешь, велика разница.
A>>Права доступа должны быть уровнем ниже бизнес-логики, иначе будут постоянные проблемы. G>Чушь повторенная несколько раз истиной не становится.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sinclair, Вы писали:
S>>Это проблема ментальной модели, и я с этой проблемой тесно знаком. Спроси ОРМ-программиста захрена он тащит в тонкого клиента полную географию США — он смотрит на тебя как на идиота и говорит "ну так мне же нужно показать список штатов в дроп-дауне". C>Это плохой ORM-программист. Нормальный программист просто вытащит список объектов типа State для заданной страны. В объекте State будет три поля "id", "name" и "abbreviation".
А если State обладает значительно более сложной структурой?
Задчача таже — отобразить список в dropdown.
Здравствуйте, adontz, Вы писали: A>Это не правда, соответственно все твои выводы тоже не правильные.
Да ладно. A>И получать кучу несогласованных кешей, о чём я уже и говорил.
Нет. От повторения заблуждение не станет правдой. Ты просто неправильно трактуешь кэш.
A>Кто говорил о полной реплике? По-моему, я ясно дал понять, что неполная реплика вполне может быть целостной.
Только не дал понять, как этого добиться. A>И насчёт "войны", я опять таки говорил, что обновление кеша необходимо только при модификации объекта.
Ага. И чем больше кэш — тем больше шанс на обновление. Рома, мы всё это уже проходили. И клинышки для подпорок для костылей, и репликацию. И даже predicate-based caching я в свое время пристально рассматривал, а это вам с Cyberax еще только предстоит изобрести.
A>Антон, это всё очень интересно, но к практике отношения не имеет. Чтобы считать дельту надо иметь две версии ответа: старую и новую, для каждого клиента. Кешировать все ответы для всех клиентов? Нет, это не реально.
Рома, это не только реально — это работает. Ну почитай наконец RFC, которые я приводил. Не нужно иметь две версии ответа — достаточно таймстампов. Кэшированием всех ответов для всех клиентов занимаются, естественно, сами клиенты. Именно таким образом работает кэширование в HTTP.
A>Более того, дело даже не в объёмах данных, а во времени отклика. Пустой запрос к серверу может отожрать секунду и интерфейс начнёт сильно тормозить, когда кто-то качает фильм через торент.
Какой еще фильм через торрент? Рома, мы же говорим о Linq между апп-сервером и дб-сервером. Разве нет? К ORM, где толстые объекты живут прямо на стороне клиента, я отношусь крайне скептически.
A>А ещё, бывает, что соединение с сервером есть не всегда. Linq более или менее приемлем только для веб-сайтов и то ИМХО вызывает проблемы. Для клиент-серверных (и n-tier в целом) систем он неприемлем вообще.
Да ладно.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>1. Зачем заниматься генерацией ненужного кода?
Проверка прав доступа — ненужный код?
S>2. Если даже код нужный, то почему не сделать генерацию прозрачной? Например, она может происходить в тот момент, когда запрос собран и происходит вызов .ToArray().
А кто сказал, что она непрозрачна?
S>Пример хорошей генерации кода: IL->x86. S>Пример плохой генерации кода: генерация сотен хранимок "просто так".
Не просто хранимок. Создаётся уровень убстракции не позволяющий обращаться к данным без проверки прав доступа. Более того, эта проверка согласована. Если у тебя есть право на чтение заказа, но нет права на чтение товара, клиента, периода времени, то заказ не будет возвращён.
A>> Вызвать IQueryable<T> SecurityCheck<T>(IQueryable<T> source) можно запросто забыть. A>>Ничто тебя не обязывает к этому вызову. Права доступа должны быть уровнем ниже бизнес-логики, иначе будут постоянные проблемы. S>Права доступа зачастую и есть часть бизнес-логики.
Здравствуйте, gandjustas, Вы писали: G>А если State обладает значительно более сложной структурой?
Ну конечно же обладает. У State там дофига всего лежит — начиная от значения VAT и заканчивая ссылкой на текущего губернатора. А если этого там нету, так это означает, что фактически класс StateEntity уже был искусственно обрезан до StateNameInfo, только неявно, в голове архитектора.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>> Какая разница, размазывать логику или нет, если хранимки генерируются? G>>Так что, хранимки генерируются на ВСЕ возможные запросы? В хранимках страшная каша будет из бизнес-логики и деталей представления. A>Ещё раз, я не считаю механизмы проверки прав доступа бизнес-логикой.
А это тут причем?
Пример из моего кода: нужно выбрать все проекты видимые проекты с заданной картинкой в заданной категории, у которых есть видимые клиенты.
В одном месте мне нужно отобразить список из назавния и услуг, связанных с проектом. А в другом месте надо отобразить 3 последних проекта из той же выборки, но уже с картинкой и описанием.
Фактически две выборки отличаются только деталями представления.
В твоем случе это будут разные хранимки?
A>>> Вызвать IQueryable<T> SecurityCheck<T>(IQueryable<T> source) можно запросто забыть. Ничто тебя не обязывает к этому вызову. G>>Для этого существуют механизмы AOP как compile-time, так и runtime. A>Ну атрибут забудешь, велика разница.
Ну так вообще что угодно забыть можно Даже вызывать генератор хранимок.
Здравствуйте, Sinclair, Вы писали:
S>Нет, не привёл. Ты искусственно потребовал "собрать граф объектов" без малейшей мотивации того, для чего он тебе нужен.
Нет, я не потребовал. Я показал, что кеширование отдельных запросов без преобразования в объекты приводит к несогласованности данных кешах запросов. А вот если собрать граф объектов, то такой несогласованности не будет.
S>Это проблема ментальной модели, и я с этой проблемой тесно знаком. Спроси ОРМ-программиста захрена он тащит в тонкого клиента полную географию США — он смотрит на тебя как на идиота и говорит "ну так мне же нужно показать список штатов в дроп-дауне".
Антон, второй раз повторяю. Я никогда не говорил о полной реплике. Это понятно?
A>>С авиарейсами разговор беспредметный, потому что не ясна задча — что делать с данными, как обрабатывать. S>Правильно. Приведи предметный пример, который не сводится к задаче "хочу граф объектов и чтобы внутри обязательно были сцылки".
Здравствуйте, Sinclair, Вы писали:
A>>Кто говорил о полной реплике? По-моему, я ясно дал понять, что неполная реплика вполне может быть целостной. S>Только не дал понять, как этого добиться.
Ну то есть вся проблема в том, что ты не умеешь получать такой кеш А вот весь фокус в тех самых генерируемых проверках прав доступа в генерируемых хранимках проблема в том, что вручную такое написать простон е реально. код логически простой, но большой по объёму, запутаться легко.
A>>И насчёт "войны", я опять таки говорил, что обновление кеша необходимо только при модификации объекта. S>Ага. И чем больше кэш — тем больше шанс на обновление.
Каким образом интеснивность работы пользователя зависит от размера кеша?
S>Рома, это не только реально — это работает. Ну почитай наконец RFC, которые я приводил. Не нужно иметь две версии ответа — достаточно таймстампов. Кэшированием всех ответов для всех клиентов занимаются, естественно, сами клиенты. Именно таким образом работает кэширование в HTTP.
Еслинственный практический случай delta в HTTP который я помню это SVN. И там у сервера есть старая и новая версии. Как ты собираешься на сервере строить разницу между старой и новой версией, если он не имеет доступа к обеим?
A>>Более того, дело даже не в объёмах данных, а во времени отклика. Пустой запрос к серверу может отожрать секунду и интерфейс начнёт сильно тормозить, когда кто-то качает фильм через торент. S>Какой еще фильм через торрент? Рома, мы же говорим о Linq между апп-сервером и дб-сервером. Разве нет?
Здравствуйте, adontz, Вы писали: A>Проверка прав доступа — ненужный код?
Хранимка — ненужный код. Зачем она, если можно просто построить запрос и выполнить его?
A>А кто сказал, что она непрозрачна?
Никто не сказал. Но я не имею опыта эксплуатации системы, где хранимки автоматически порождаются Just In Time и убиваются, когда они больше не нужны.
A>Не просто хранимок. Создаётся уровень убстракции не позволяющий обращаться к данным без проверки прав доступа. Более того, эта проверка согласована. Если у тебя есть право на чтение заказа, но нет права на чтение товара, клиента, периода времени, то заказ не будет возвращён.
Рома, не нужно агитации. Этот уровень абстракции делает поразительно мало в обмен на геморрой по его поддержанию в up-to-date состоянии. Вся та же функциональность вполне доступна и без генерации хранимок. Я показал, как именно. Страшилки про "а вдруг кто-то забудет обратиться к предикату" идут в топку, потому что это прямой аналог вопроса "а если я сделаю прямой селект из таблицы мимо хранимки".
Если сильно страшно, то можно поставить проверку наличия предиката безопасности прямо в том месте, где запрос начинает исполняться.
A>Установка прав — да, проверка — нет.
Да ладно! "Младший менеджер не имеет права отгружать заявку дороже 50000р без подтверждения старшего менеджера" — это что, не бизнес-логика? Спустись с небес на землю.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
. Всё равно в основе лежит Expr<Func<T, T>>. 
