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

C>>Это плохой ORM-программист. Нормальный программист просто вытащит список объектов типа State для заданной страны. В объекте State будет три поля "id", "name" и "abbreviation".
G>А если State обладает значительно более сложной структурой?
То это плохая архитектура

G>Задчача таже — отобразить список в dropdown.
В крайнем случае — делается специальный DTO.

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

G>Пример из моего кода: нужно выбрать все проекты видимые проекты с заданной картинкой в заданной категории, у которых есть видимые клиенты.
G>В одном месте мне нужно отобразить список из назавния и услуг, связанных с проектом. А в другом месте надо отобразить 3 последних проекта из той же выборки, но уже с картинкой и описанием.
G>Фактически две выборки отличаются только деталями представления.
G>В твоем случе это будут разные хранимки?

Не уверен, что правильно понял задачсу. Можно подробнее?

A>>>>

Вызвать IQueryable<T> SecurityCheck<T>(IQueryable<T> source) можно запросто забыть. Ничто тебя не обязывает к этому вызову.
G>>>Для этого существуют механизмы AOP как compile-time, так и runtime.
A>>Ну атрибут забудешь, велика разница.
G>Ну так вообще что угодно забыть можно Даже вызывать генератор хранимок.

Ну тогда у тебя не будет всех хранимок Это легко заметить.

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

A>>Не просто хранимок. Создаётся уровень убстракции не позволяющий обращаться к данным без проверки прав доступа. Более того, эта проверка согласована. Если у тебя есть право на чтение заказа, но нет права на чтение товара, клиента, периода времени, то заказ не будет возвращён.
S>Рома, не нужно агитации. Этот уровень абстракции делает поразительно мало в обмен на геморрой по его поддержанию в up-to-date состоянии. Вся та же функциональность вполне доступна и без генерации хранимок. Я показал, как именно. Страшилки про "а вдруг кто-то забудет обратиться к предикату" идут в топку, потому что это прямой аналог вопроса "а если я сделаю прямой селект из таблицы мимо хранимки".

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

S>Если сильно страшно, то можно поставить проверку наличия предиката безопасности прямо в том месте, где запрос начинает исполняться.

И там тоже можно забыть.

A>>Установка прав — да, проверка — нет.
S>Да ладно! "Младший менеджер не имеет права отгружать заявку дороже 50000р без подтверждения старшего менеджера" — это что, не бизнес-логика? Спустись с небес на землю.

Это не те права доступа, о которых я говорил.

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

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

S>>Нет, не привёл. Ты искусственно потребовал "собрать граф объектов" без малейшей мотивации того, для чего он тебе нужен.
A>Нет, я не потребовал. Я показал, что кеширование отдельных запросов без преобразования в объекты приводит к несогласованности данных кешах запросов. А вот если собрать граф объектов, то такой несогласованности не будет.
Именно эта фраза подтевржадет то что кеш в ORM-системах может быть только глобальный.

A>>>С авиарейсами разговор беспредметный, потому что не ясна задча — что делать с данными, как обрабатывать.
S>>Правильно. Приведи предметный пример, который не сводится к задаче "хочу граф объектов и чтобы внутри обязательно были сцылки".
A>http://www.rsdn.ru/forum/message/3358676.1.aspx

Автор: adontz
Дата: 12.04.09

A>Задача получения согласованных данных на уровне Linq-подобных запросов не решается.\
Кажестся я уже описывал, что эта задача и другими способами нормально не решается.
Вообще если между двумя запросами свзязанных данных проходит какое-то время, то всегда можно нарваться на рассогласованность, и без пессимистичной блокировки этих данных в общем случае победить такое нельзя.

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

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

C>>>Это плохой ORM-программист. Нормальный программист просто вытащит список объектов типа State для заданной страны. В объекте State будет три поля "id", "name" и "abbreviation".
G>>А если State обладает значительно более сложной структурой?
C>То это плохая архитектура
С чего это? Может основная функция системы в работе с географией и административными субъектами.
Или выбор штата в дропдауне — плохая архитектура?

G>>Задчача таже — отобразить список в dropdown.
C>В крайнем случае — делается специальный DTO.
А потом появляются более сложные сценарии, когда для формирования DTO нам нужно соединение таблиц, группировки данных...
Обобщая такие крайние случаи и получим модель запросов и полновесный ORM нам никак не поможет.

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

C>>То это плохая архитектура
G>С чего это? Может основная функция системы в работе с географией и административными субъектами.
Тогда да, хотя там тоже под вопросом. Но в этом случае скорее всего эта информация и так понадобится в программе, так что осбого вопроса с загрузкой словаря не будет.

G>Или выбор штата в дропдауне — плохая архитектура?
Это тоже не очень удачный выбор — 50 элементов уже многовато для комбобокса.

C>>В крайнем случае — делается специальный DTO.
G>А потом появляются более сложные сценарии, когда для формирования DTO нам нужно соединение таблиц, группировки данных...
G>Обобщая такие крайние случаи и получим модель запросов и полновесный ORM нам никак не поможет.
DTO — это всего лишь объект передачи данных, тот же кортеж им вполне может быть. В этом случае просто всё у нас скатывается к SQL-подобному доступу.

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

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

G>>Пример из моего кода: нужно выбрать все проекты видимые проекты с заданной картинкой в заданной категории, у которых есть видимые клиенты.
G>>В одном месте мне нужно отобразить список из назавния и услуг, связанных с проектом. А в другом месте надо отобразить 3 последних проекта из той же выборки, но уже с картинкой и описанием.
G>>Фактически две выборки отличаются только деталями представления.
G>>В твоем случе это будут разные хранимки?
A>Не уверен, что правильно понял задачсу. Можно подробнее?

Лучше более обще опишу: есть выборка, полученная наложением кучи условий, соединений, группировок (неважно каких).
В интерфейсе эта выборка используется в двух местах, в каждом из них надо отображать свой набор полей выборки, со своими условиями сортировки.
Внимание вопрос: это будет две разные хранимки?

Здравствуйте, adontz, Вы писали:
A>Нет, я не потребовал. Я показал, что кеширование отдельных запросов без преобразования в объекты приводит к несогласованности данных кешах запросов.
Да нихрена ты не показал.
A>http://www.rsdn.ru/forum/message/3358676.1.aspx

Автор: adontz
Дата: 12.04.09

A>Задача получения согласованных данных на уровне Linq-подобных запросов не решается.
1. Если ты хотел гарантий согласованности, то читал бы их в одной транзакции с уровнем изоляции Serializable и никакой несогласованности бы не увидел. RTFM.
2. Про штампы времени ты допустил ошибку: у тебя вовсе не "последние версии таблицы городов". Сама постановка вопроса показывает наличие клина в голове: ты не получал в результате никаких таблиц. Ты получил результат запроса. Результат запроса c (CityName, CustomerCount), естественно, устарел.
Теперь специально для тех, кто быстро пишет и медленно думает, поясняю, каким образом работает timestamp-based cache refresh в приведенном тобой случае.

select 
City.Name, CustomerStats.customerCount, CustomerStats.LastModified 
from Cities 
inner join 
  ( select cityId, count(*) as customerCount, max(lastModified) as LastModified from customers group by cityId) CustomerStats
on Cities.ID = CustomerStats.cityID

Теперь для delta encoding достаточно получить с клиента таймстамп его результата, и добавить к запросу:

select 
City.Name, CustomerStats.customerCount, CustomerStats.LastModified 
from Cities 
inner join 
  ( select cityId, count(*) as customerCount, max(lastModified) as LastModified from customers group by cityId) CustomerStats
on Cities.ID = CustomerStats.cityID
where CustomerStats.LastModified > @LastModified

Понятно, как это работает?

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


A>Каким образом интеснивность работы пользователя зависит от размера кеша?
Ну так обновление кэша зависит от интенсивности работы других пользователей. Вот у меня стоит янус со своим кэшем. Объем скачиваемых им изменений зависит, Рома, не от моих усилий, а от твоих. И чем на большее количество форумов я подпишусь, тем больше будет трафик.

A>Еслинственный практический случай delta в HTTP который я помню это SVN. И там у сервера есть старая и новая версии. Как ты собираешься на сервере строить разницу между старой и новой версией, если он не имеет доступа к обеим?
Рома, почитай RFC про Delta Encoding. Там, вроде бы, был пример того, как строить дельты.

A>Нет. Мы говорим об клиенте и апп-сервере
Ну, тогда я не уверен, что понимаю что и зачем мы пытаемся изобрести. Какой тут нафиг ORM вообще? Зачем он нужен? Я могу себе представить ситуацию, в которой толстый клиент лучше тонкого, но в этих ситуациях протоколы репликации строго ортогональны собственно функциям клиента. Я сильно сомневаюсь, что к ним будет нужен какой-то линк или еще что-то. При этом собственно взаимодействие кода клиента с локальными данными по-прежнему может строиться на линке.

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

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

C>>>То это плохая архитектура
G>>С чего это? Может основная функция системы в работе с географией и административными субъектами.
C>Тогда да, хотя там тоже под вопросом. Но в этом случае скорее всего эта информация и так понадобится в программе, так что осбого вопроса с загрузкой словаря не будет.
Угу, вот про это и разговор. "информация скорее всего и так понадобится в программе" — первая отмазка ORM-щиков когда им говрят про слишком большой объем данных на клиенте.

G>>Или выбор штата в дропдауне — плохая архитектура?
C>Это тоже не очень удачный выбор — 50 элементов уже многовато для комбобокса.
Для хорошо известных элементов — нормально.
Страны, штаты, области, города — вполне нормально уживаются в комбобоксах. А вот список сотрудников в комбобоксе — хреновое решение.

C>>>В крайнем случае — делается специальный DTO.
G>>А потом появляются более сложные сценарии, когда для формирования DTO нам нужно соединение таблиц, группировки данных...
G>>Обобщая такие крайние случаи и получим модель запросов и полновесный ORM нам никак не поможет.
C>DTO — это всего лишь объект передачи данных, тот же кортеж им вполне может быть. В этом случае просто всё у нас скатывается к SQL-подобному доступу.
Так если SQL-подобный доступ совместить с механизмом отображения полей БД на свойства объектов данных (DTO), то будет счастье. Об этом и говорим.

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

G>Угу, вот про это и разговор. "информация скорее всего и так понадобится в программе" — первая отмазка ORM-щиков когда им говрят про слишком большой объем данных на клиенте.
Нет, ты это сам придумал, что объект штата будет большим из-за того, что программа предназначена для работы с географией.

Если программа для работы с географией не предназначена, то раздувание объекта типа "штат" — это плохой дизайн.

G>>>Обобщая такие крайние случаи и получим модель запросов и полновесный ORM нам никак не поможет.
C>>DTO — это всего лишь объект передачи данных, тот же кортеж им вполне может быть. В этом случае просто всё у нас скатывается к SQL-подобному доступу.
G>Так если SQL-подобный доступ совместить с механизмом отображения полей БД на свойства объектов данных (DTO), то будет счастье. Об этом и говорим.
Тебе говорят, что в большинстве случаев ORM не даёт существенного overhead'а, поэтому и DTO не нужны. Для редких случаев, когда overhead от ORM слишком велик — используем DTO. Ситуация примерно как с ассмеблерными вставками раньше — оптимизируем только узкие места.

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

A>Антон, разница есть существенная. Чтобы забыть обратиться к предикату надо забыть написать один вызов функции.
A>Чтоб сделать SELECT из таблицы напрямую, надо очень сильно помучатсья и очень много чего написать.

A>И там тоже можно забыть.
Рома, ты наверное плохо понимаешь. Все запросы, которые ты пишешь в линке, проходят через один и тот же енжин. Поэтому можно поставить эту проверку ровно в 1 (одном) месте, и больше никогда не бояться что-то пропустить.

A>Это не те права доступа, о которых я говорил.
Ну так понятно — ты говорил о каких-то других правах доступа, чем те, которые реально нужны.

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

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

G>>Угу, вот про это и разговор. "информация скорее всего и так понадобится в программе" — первая отмазка ORM-щиков когда им говрят про слишком большой объем данных на клиенте.
C>Нет, ты это сам придумал, что объект штата будет большим из-за того, что программа предназначена для работы с географией.
C>Если программа для работы с географией не предназначена, то раздувание объекта типа "штат" — это плохой дизайн.
все что не укладывается в ORM — плохой дизай, ага.

G>>>>Обобщая такие крайние случаи и получим модель запросов и полновесный ORM нам никак не поможет.
C>>>DTO — это всего лишь объект передачи данных, тот же кортеж им вполне может быть. В этом случае просто всё у нас скатывается к SQL-подобному доступу.
G>>Так если SQL-подобный доступ совместить с механизмом отображения полей БД на свойства объектов данных (DTO), то будет счастье. Об этом и говорим.
C>Тебе говорят, что в большинстве случаев ORM не даёт существенного overhead'а, поэтому и DTO не нужны.
Полновесный ORM дает оверхед не только в объеме данных.

C>Для редких случаев, когда overhead от ORM слишком велик — используем DTO.
Нормальные люди используют запросы и не парятся с DTO, ORM и другими трухбуквенными сочетаниями.

C>Ситуация примерно как с ассмеблерными вставками раньше — оптимизируем только узкие места.
Неверная аналогия. SQL обладает большими возможностями, чем GetById, FindByName и прочее.

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

L>>>

L>>>MVC is often seen in web applications, where the view is the actual HTML or XHTML page, and the controller is the code that gathers dynamic data and generates the content within the HTML or XHTML.

L>>>Ты все еще уверен, что я неправильно понимаю MVC?

VD>>MVC — это общий архитектурный паттерн и допускает очень вольную трактовку. Но основная суть его — это отделение логики данных от презентационной логики и от логики управления.

L>Странно, а пару часов назад было
L>

L>Ни модель, ни представление не должны знать о контроллере.

L>

А что в приведенных цитатах есть противоречия?

VD>>Так что чем квотить мелкий кусочик из википедии (не являющейся точным источником данных, кстати) ты прочел бы хотя бы весь раздел. А еще лучше прочитай первоисточник.

L>

L>Unlike the model, which may be loosely connected to multiple MVC triads, Each view is associated with a unique controller and vice versa. Instance variables in each maintain this tight coupling.

L>

Опять же, что ты тут вычитал? Нашел несоответствие с описанием в Википедии?

VD>>Короче понимание MVC — это отдельный вопрос. К сожалению его не понимают очень многие. Не уверен в проценте, но не удивлюсь, если это 70%.

L>Твои догадки подтверждаются.

Ага. И таких как ты большинство.

L>>>Да все это понятно. Поинт лишь в том, что пихать это в presentation — последнее дело.

VD>>Что это? Доступ к модели? А куда же его пихать, то?

L>В контроллер, другого не остается.

Иди и еще раз прочитай задачи контроллера. Если в контроллере будет логика отображения, то это будет смешиванием логики отображения и логики управления, то есть нарушением базового принципа MVC.

Короче, в данной теме я не намерен продолжать обсуждение паттерна MVC. Если тебе интересно, заводи новую тему.

L>>>UI должен быть туп как пробка и не должен содежать ни методов для формирования чего-либо, ни оперировать запросами.

VD>>Кто сказал такую чушь? Задача представления — отображать данные модели. Какова сложность этого зависит исключительно от двух факторов — сложности представления и сложности модели. Если представление отображает не всю модель целиком, то нужны хорошие инструменты выбрать нужные для отображения данные.

L>Если подходить формально, то ты прав. А на практеке от кода еще стребуется как минимум тестируемость. Если мы зашиваем часть логики запросов в представление, мы эту возможность теряем.

Интересный поворот. С доказательством нарушения принципов MVC не вышло, переключаемся на тестирование...
При желании организовать тестирование презентационной логике тоже можно. Но это опять таки очередное отклонение от темы. Главное, что для этого нет нужды выносить презентационную логику из представления.

L>Лучше от мыслительного процесса переходить к практике.

То есть, трясти, а не думать? Это подход прапорщиков.

L>Как тогда скрывать детали маппинга? Я кажется, догадываюсь, что ты ответишь. В задницу сокрытие деталей. Оно?

У тебя будут объекты на которые идет отображение. Вот они и будут скрывать все что нужно. Можешь считать их DAL-ом.
Мне больше нравится терминология MVC. В ней данные объекты являются публичным интерфейсом модели.

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

S>А, вот наверное и есть то решение, которое всему поможет.

Именно.

S>Но вот насчёт примитивности я не уверен.
S>Как только ты сделал два типа совместимыми, начинаются разнообразные смешные сценарии использования — например, употребить тип в параметре делегата.

И какие здесь проблемы?

S>Или отнаследоваться от такого "типа со структурной идентичностью".

Тут много вариантов решения. Самое простое решение — обязать помечать типы помечаемые атрибутом структурной идентичности модификатором sealed.

S>В итоге получается большое количество corner cases, которые должны работать осмысленным образом. Это существенно увеличивает объем QA.

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

S>Ну вот к примеру — будут ли два массива таких типов совместимы по присваиванию, как это работает для string[]->object[]?

Я считаю, что коваринтность массивов — это ошибка дизайна. На практике данная возможность практически не используется, но вреда для производительности создает не мало. Но это отдельная тема.
В данном случае массивы обязаны быть совместимы просто потому, что два таких типа обязаны рассматриваться как один. В прочем, даже если это будет не так особых проблем не возникнет.

S>Регистр тут ни при чём. {string Name, int Age} должен быть совместимым с любым {string, int}. См. SQL — там это используется сплошь и рядом.

Мой ответ — нет. Но, если что можно произвести копирование через совместимый по типам кортеж. Вот кортежи должны сравниваться только по типам элементов.

S>В чем отличие? Зачем иметь два типа, выполняющих сходную функцию? Имхо, вполне достаточно одного, но полноценного.

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

VD>>Скажем так. Реализовать копирование между записями и кортежами.
S>С копированием есть еще несколько тонких вопросов — это же операция, нарушающая идентичность.

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

S> Хотя, если считать, что ее у структурных типов быть вовсе не должно... Тем не менее, копирование не спасает для приведения друг к другу IEnumerable<T> и T[]. А без него смысла во взаимозаменяемости особого нету.

VD>>А вот это плохое решение. Лучше ввести атрибут структурной совместимости и пометить ими анонимные типы.
S>Почему плохое?

Откровенно говоря не понимаю причем тут приведение IEnumerable<T> и T[]. Я, видимо, потерял ход мысли.

VD>>А если бы была структурная совместимость, то проблем бы не возникло. Так что вердикт ясен как божий день. Еще один косяк в системе типов донета который Майкрософт упорно не хочет исправлять.
S>Ну, не факт, что не хочет, и не факт, что упорно. Я вот, с учетом малого опыта работы с ФП-языками, пока что плохо представляю даже постановку задачи.

У команде МС работающей над дотнетом теперь есть Меер который является одним из создателем Хаскеля. Так что у них есть кому объяснить. Если только возникает та же ситуация что у нас, когда другие члены команды не могут понять одного из них.

Собственно на твоем месте я бы почитал что-нить о системе типов ML-я.
Кстати апофеозом развития системы типов в ФЯ стали классы типов Хасклея. Очень интересная концепция близкая к интерфейсам явы/дотнета. Если не знаком с ней, очень советую познакомься.

VD>>Потому что ты исходишь из неверных предпосылок. Нужно не заплаты придумывать, а ошибки исправлять.
S>Ну, если есть детальное представление о том, как именно нужно исправить ошибку — то велкам.

Куда? Меня в группу разработки CLR никто не завл. И даже мнения не спрашивал.
В прочем, я там и н нужен. Меера достаточно. Просто нужно постараться понять то, что он говорит.

Здравствуйте, VladD2, Вы писали:
VD>И какие здесь проблемы?
Простые. Будет ли верифицироваться операция подписки на событие, если аргументом делегата выступает один из структурно-совместимых типов, а аргументом события — потомок другого.
VD>Тут много вариантов решения. Самое простое решение — обязать помечать типы помечаемые атрибутом структурной идентичности модификатором sealed.
Или, что в принципе то же самое, реализовать их как value-типы. Один хрен reference-семантика им только мешает.

VD>Не выдумывай. Данная возможность реализована в большинстве ФЯ. Так что все проблемы надуманы. Просто не надо жить в догмах системы типов донета. Надо ее немного расширить.
В большинстве ФЯ не заморачиваются интероперабельностью с существующей системой типов CLR. Исключений, в общем-то, два: F# и сами-знаете-кто. Поэтому от мажорного контрибутора в один из них я инстинктивно ожидаю более развернутых комментариев

VD>Я считаю, что коваринтность массивов — это ошибка дизайна. На практике данная возможность практически не используется, но вреда для производительности создает не мало. Но это отдельная тема.

VD>В данном случае массивы обязаны быть совместимы просто потому, что два таких типа обязаны рассматриваться как один. В прочем, даже если это будет не так особых проблем не возникнет.


VD>Мой ответ — нет.
В таком случае полезность от анонимных типов резко уменьшится. Смотри: наследоваться ты им только что запретил; интерфейсы в них никак не реализуешь.
Это означает, что надо быть крайне осторожным при изготовлении кода. Уже не получается сделать метод AddFinancialSecurityCheck, который гарантирует запрет доступа младшего персонала к любым документам с суммой больше $5000 USD. Этот метод будет гвоздями прибит к совершенно конкретному типу результата.
Это, конечно, не так плохо, как сведение всех запросов к небольшому набору full-blown classes с ORM, но всё равно снижает возможности по декомпозиции.
VD>Но, если что можно произвести копирование через совместимый по типам кортеж. Вот кортежи должны сравниваться только по типам элементов.
Угу.

VD>Они различны. Имена полей — это дополнительная информация о типе. Если разрешить плевать на нее, то могут вылезать неприятные ошибки.
VD>Опять же есть туча языков где есть и кортежи, и записи. Они четко демонстрируют, что ничего лишнего в этом нет. Более того их системы типов проектировались серьезными людьми и долго продумывались.
Ну, я-то мало с этим знаком. Если есть какие-то письменные источники, то я бы почитал. А то приходится выдумывать велосипеды, глядя на конкретные проблемы конкретного фреймворка.

VD>Копирование должно осуществляться только для типов между которыми оговорена структурная идентичность. Потом под копированием я понимаю создание нового экзепляра одного типа, на основе данных другого, а не банальное переписывание памяти.
Это понятно. Я не про это, а про то, что если у типа reference семантика, то программист получит весьма неожиданный результат при попытке выполнить сравнение через ==.

VD>Откровенно говоря не понимаю причем тут приведение IEnumerable<T> и T[]. Я, видимо, потерял ход мысли.
Про массивы ты уже высказался. Осталось понять, должен ли IEnumerable< { string Name, int Age} > быть автоматически приводимым к IEnumerable<Tuple<string, int>>.

VD>Собственно на твоем месте я бы почитал что-нить о системе типов ML-я.
VD>Кстати апофеозом развития системы типов в ФЯ стали классы типов Хасклея. Очень интересная концепция близкая к интерфейсам явы/дотнета. Если не знаком с ней, очень советую познакомься.

VD>Куда? Меня в группу разработки CLR никто не завл. И даже мнения не спрашивал.
Зато я могу написать гадостей в csharp-insiders mailing list. Что я и делаю, но у меня не хватает компетентности.

VD>В прочем, я там и н нужен. Меера достаточно. Просто нужно постараться понять то, что он говорит.

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

A>>А кто сказал, что она непрозрачна?
S>Никто не сказал. Но я не имею опыта эксплуатации системы, где хранимки автоматически порождаются Just In Time и убиваются, когда они больше не нужны.

Они не порождаются just-in-time

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

A>>Нет, я не потребовал. Я показал, что кеширование отдельных запросов без преобразования в объекты приводит к несогласованности данных кешах запросов. А вот если собрать граф объектов, то такой несогласованности не будет.
G>Именно эта фраза подтевржадет то что кеш в ORM-системах может быть только глобальный.

Ты не прав Вполне можно построить ссылочноцелостное подмножество данных БД, по объёму значительно меньше данныхв БД.

G>Кажестся я уже описывал, что эта задача и другими способами нормально не решается.
G>Вообще если между двумя запросами свзязанных данных проходит какое-то время, то всегда можно нарваться на рассогласованность, и без пессимистичной блокировки этих данных в общем случае победить такое нельзя.

Ты опять таки не прав.

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

G>Лучше более обще опишу: есть выборка, полученная наложением кучи условий, соединений, группировок (неважно каких).
G>В интерфейсе эта выборка используется в двух местах, в каждом из них надо отображать свой набор полей выборки, со своими условиями сортировки.
G>Внимание вопрос: это будет две разные хранимки?

it depends.
Если это отчёт для экспорта в Excel и печати на принтере, то два разных запроса.
Если это данные которые потенциально могут редактироватся, то скорее всего один запрос.
Возможно, если сама сущность тяжёлая, например у сотрудника фотография 5 на 6 метров, и тяжёлая часть (фотография) нужна редко, то, возможно, что список сущностей будет загружаться в два этапа. Экономить память и трафик иногда не передавая дату рождения из 8 байт я считаю не разумным.

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

S>1. Если ты хотел гарантий согласованности, то читал бы их в одной транзакции с уровнем изоляции Serializable и никакой несогласованности бы не увидел. RTFM.

Ага, только вот между чтениями может пройти существенное количество времени (минуты). Не вариант.

S>2. Про штампы времени ты допустил ошибку: у тебя вовсе не "последние версии таблицы городов". Сама постановка вопроса показывает наличие клина в голове: ты не получал в результате никаких таблиц. Ты получил результат запроса. Результат запроса c (CityName, CustomerCount), естественно, устарел.
S>Теперь специально для тех, кто быстро пишет и медленно думает, поясняю, каким образом работает timestamp-based cache refresh в приведенном тобой случае.
S>

S>

S>Понятно, как это работает?

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