Здравствуйте, Sinclair, Вы писали:
IT>>Напрасно. Мне это тоже не нравится, но отсальное не нравиться ещё больше. S>Ты смотрел на Building IQueryable Provider XIII?
Смотрел, мне семантика == тоже не нравится по тем же причинам — перекладывание большинства проверок на рантайм.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Sinclair, Вы писали:
S>Ну вот собсно основная штука в value-семантике — именно "сравнение работало корректно (по значениям полей)". Или я неправильно понимаю разницу между value- и reference- семантиками?
Дык операторы и методы сравнения можно переопределить как надо. Для тех же кортежей в немерле так и сделано.
VD>>Ты смотришь не с той колокольни. F# и Nemerle вынуждены ограничиваться системой типов дотнета и эмулировать функциональные типы на том, что есть. S>Ну, я что вижу — то пою. Вот ты ссылку дал про ML — надо будет посмотреть.
Я могу сказать как разработчик (фактический) того же Nemerle. Я не стал возиться с анонимным типами по двум причинам.
1. Не хочется вводить в язык неполноценное решение.
2. Есть кортежи которые и так позволяют решать проблему и при этом являются полноценным решением.
Однако я с удовольствием сделал бы поддержку полноценных анонимных типов а-ка записей если бы их поддерживал CLR.
VD>>Я вообще не понимаю, почему ты не критикуешь скажем анонимные типы C#-а. Ведь они не допускают наследования. S>Как это не критикую? Собсно, все мои потребности в записях связаны именно с убогостью существующих анон.типов.
OK. Тогда поставим вопрос по другому. Ты же не говоришь, что проблема анонимных типов заключается в отсутствии наследования. Тебе не нравится, то что их нельзя возвращать из метода. Так?
S>Ну, так я согласен. Осталось понять, как решить эту проблему.
Дык надо всего лишь позволить рассматривать два типа как один если у них одинакова структура. Пусть будут запрещено наследование. Это не помеха. Тогда останется придумать и реализовать синтаксис для описания анонимного типа.
И главное понять, то этот не имеет никакого отношения к ООП. По этому не стоит рассуждать об инкапсуляции, полиморфизме и прочем (хотя последнее как раз весьма возможно).
S>OMFG, 422 results. Да, это определенно достаточно много работ, чтобы занять меня на следующие тридцать вечеров пятницы.
Реально толковых ссылок там не так. Много я если тебе действительно интересен вопрос, то я бы все же начал с вопроса в Декларативном программировании. Там есть народ который такие работы вместо газет на за завтраком читал .
VD>>Достаточно просто определить соответствующие операторы. Для строк же таких проблем нет? S>Ну, возможно ты прав. Главное, чтобы нигде в выражениях не терялся тип. Иначе можно огрести эффект, сравнимый с чудесами боксинга.
Именно так. И именно по этому нужно менять рантайм.
VD>>Это было бы полезно. Не уверен на счет обраного. Впрочем явное приведение было бы тоже полезно. S>Главное — понять, какова семантика этого приведения. Будут ли при енумерировании "на лету" конструироваться новые объекты, или просто будут успешно каститься существующие.
А вот это должен скрывать рантайм. Для меня все должно быть прозрачно. Семантика должна быть как у типов-значений, но при этом сами типы могут быть просто не изменяемыми.
VD>>Написал и подумал. Если типы будут не изменяемыми, то можно просто производить копирование в нужный тип если предлагается преобразовать ссылочный тип в значение или наоборот. S>Надо проверять в реальных сценариях и смотреть, нет ли несовместимых с жизнью проблем с перформансом.
Это все проверено сто раз в функциональных языках. Даже нехилая теория под это дело подведена.
К тому же в реальных языках такие типы будут скрываться за интерфейсом каких-нить анонимных типов или записей. Так что на эти типы априори будут наложены более строгие ограничения. Например, для записей операторы сравнения будут генерироваться самим компилятором. Сравнение будет просто по полям (вызов Equals() для каждого члена). Просто соответствия структуры будет достаточно чтобы все работало как надо.
VD>>Это легко исправить. Главное понимать, что есть разные решения и не упираться в те решения, что знаешь. S>Я не упираюсь.
Дык это и радует!
S>Я хочу найти идеальное решение, и устроить флеш-моб с целью склонить к нему ответственных товарищей. Правда, меня пока что забанили в том списке — на выходных лежала даже гуглопочта нашего сайта, за что меня и тово, лишили доступа к телу.
Решение уже апробировано в ФЯ. Это записи. Анонимные типы и были содраны с них. В общем, найди литературу описывающую записи и кортежи в ML-подобных языках и сам все увидишь.
Объекты с одинаковой структурой можно сравнивать и копировать без опасений и проблем. Проблема только в поведении рантайма. Он вместо проверки совместимости на уровне типов дотнета должен осуществлять банальную структурную проверку. В реальной реализации конечно надо будет создать таблицу структурной совместимости типов и при осуществлять проверку через нее.
VD>>Я не понимаю что тут смешного? Если бы его слова были понятны всем, то идиотизма вроде анонимных типов не появилось бы, а появились бы полноценные записи и кортежи. S>Не думаю, что его слова там как-то особенно непонятны. Чуваки из CLR — вполне вменяемые. Их главное убедить, что что-то вообще нужно. Потому что их работа — это говорить "but you can achieve virtually the same result by using {workaround description}" — и это правильно. Иначе бы в CLR было бы столько навоза — не разгребешь
Ну, вот пусть они приведут воркэраунд позволяющий возвращать IQueryble<анонимный тип или список значений>.
Это же действительно бред получается. Люди не могут вынести навороченный составной запрос в отдельную функцию только потому, что авторы языка и дотнета требуют каких-то убедительных довыдов, а совершенно очевидные недоработки попросту игнорируют.
S>Ну, там пока в основном другие MVP отжигают; народ из команды как-то так, значительно менее активен. Но я попробую.
Кстати, интересно о чем они там говорят? Что их интересует? Почему-то подозреваю, что разная мелочевка.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, mrTwister, Вы писали:
T>Это же твоя собственная аргументация. Я даже выделил.
Я обосновал свое утверждение.
T>Прекрасно. Но я ничего не писал про количество ошибок.
Ты писал о защите. Я тебе продемонстрировал, что защита весьма мнимая. Чем более сложными вещами ты занимаешься, тем меньше вероятность того, что баги на которые ты напоролся будут устранены майкрософтом.
T>Количество пользователей не связано с количеством ошибок.
А что тебе дает лэйбак Майкрософт? В чем защита то? Ты же говорил о вере в том, что МС исправит какие-то там ошибки...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
L>>Мы сами подобное используем, я имею в виду создание отдельных PE для отдельных страниц. И меня совершенно не радует созерцать кучу одноразовых классов. Так что так уж однозначно называть этот способ правильным я бы не стал. S>А что именно в одноразовых классах тебя смущает?
Меня смущает то, что со временем эта куча превращается в помойку, т.к. никакой внятной схемы именования подобных классов мне придумать не удалось.
S>Меня вот гораздо больше смущает насильственное использование плохо приспособленных классов. S>Просто мы очень привыкли к тому, что класс — это дорогостоящая штука, которую надо обязательно руками описать заранее, и очень многословно. И потом нужно его поддерживать, внося изменения. S>Однако внедрение более эффективных методик порождения типов позволяет сделать эти одноразовые классы достаточно дешевыми. Те же анонимные типы использовать почти так же приятно, как и именованные, при этом нет нужды описывать их заранее в отдельном месте.
Был бы аналог удобного глобального вывода типов для анонимных классов, было бы удобно. А так приходится созерцать эти унылые CustomerInfo...
L>>Но это не является параметром выборки S>Не играй словами. Набор полей является существенным свойством оператора выборки, которое значительно влияет на производительность запроса.
Свойство хорошее слово. Его оставим как есть.
L>>Не один, а пачка: если у кастомера в адресе нужно выбрать город, то здравствуй новая PE с двумя полями ID и Name. S>Ну и что? Какие проблемы? Я не очень понимаю, что ты имеешь в виду под PE.
PE = Presentation Entity
S>Будет просто свойство ViewModel, в котором лежит коллекция пар ID и Name. Всё очень здорово и удобно.
Удобно, если ID и Name. Но если полей становится больше 2-3-х, то получаем кучу унылого говно-кода.
Здравствуйте, Sinclair, Вы писали:
A>>В базе данных можно выделить такое подмножество записей, что любая из этих записей будет ссылаться (foreign key) только на записи того же подмножества. S>Это да. Можно выделить связный подграф.
О, графы это хорошо, молодец. Хотя я тут не согласен насчёт терминологии. Мы выделяем некоторое подмножество сущностей, такое, что сущности из подмножества связаны (есть ссылка) только с сущностями из того же подмножества. Связанность подграфа тут не обязательна. Скажем, если взять пять сущностей
A <- B <- C -> D -> E
то (A, B, D, E) будет ссылочно-целостным подмножеством. Подграф A, B, D, E не связанный, но это и не надо. Гораздо важнее что ни одна из сущностей A, B, D, E не ссылается на С — сущность вне подмножества.
A>>Добавление записей не входящих в данное подмножество непосредственно, не расширяет его. S>Этого утверждения я не понял. Добавление куда? Не расширяет кого?
Это очень просто. Пусть есть 4 сущности: A, B, C, D. Пусть они ссылаются друг на друга следующим образом A->B, A->C, D->A, D->B. Одним из указанных мною подмножеств будет (A, B, C). Хотя D и ссылается на сущности A и B, важно что A, B и C не ссылаются на D. Теперь, если добавить сущность E и ссылки E->A, E->C, то на (A, B, C) это никак не отразится и (A, B, C) останется ссылочно-целостным подмножеством сущностей.
A>>Множество записей необходимых для работы (кроме отчётов) конкретному пользователю значительно, на порядки, меньше общего количества записей. S>Ок, от подграфа мы отошли к каким-то "необходимым для работы" записям.
Нет. Речь идёт о минимальном ссылочно-целостном подмножестве сущностей включающем в себя все данные необходимые для работы.
S>1. Этих записей значительно, на порядки, меньше общего количества записей.
Теоретически для всех возможных задач такого доказать, конечно же, нельзя. А вот исходя из практики, моего опыта, да, так и есть.
S>2. Обеспечение актуальности кэша именно этих записей обеспечивает ссылочную целостность всей БД
Обеспечение ссылочной целостности этого кеша обеспечивает корреткность операций. Не допустимость, а корректность. Для большинства операций нет необходимости иметь последние, потому что для большинства операций необходимые данные в кеше не меняются. Как часто, например, меняется список филиалов, клиентов, товаров? Так ли необходимо иметь актуальную версию списка при оформлении каждой операции, а следовательно перед каждой операцией проверять обновления?
В некоторых случаях актуальность важна. Например, прежде чем оформлять заказ на клиента, надо проверить что клиент не заблокирован за долги. Эту логику надо размещать на сервере. Но заметь, запрет на действие никак не связан с актуальностью кеша на клиенте. Если у оператора открылось окно оформления заказа, потому что клиент в кеше не заблокирован, но не оформился заказ, потому что клиент заблокирован в центральной БД, никакой катастрофы в этом, по большому счёту нет. Главное, выдать вменяемое сообщение, почему так произошло.
Более того, есть мобильные торговые агенты. Человек берёт в руки покет, изредка ноутбук, и ездит по клиентам. "Ловит" не везде. Заказ, на уже заблокированного клиента может быть успешно сохранён в кеш, а загрузка его в центральную БД, и отказ в оформлении, произойдёт только вечером. Тут тоже нет никакой катастрофы. Если данный кеш ссылочно-целостный, то у меня не самая последняя версия БД, но достаточная для работы. Это значит, что просматривая объекты кеша и переходя по ссылкам мне не потребуется что-то запрашивать с сервера.
S>3. Обеспечение актуальности кэша именно этих записей менее затратно, чем обеспечение актуальности кэша результатов конкретных запросов.
По трафику и количеству запросов, без сомнения.
A>>Это, вообще говоря, не верно. Налагая условия на схему БД можно прочесть полностью целостную реплику БД вообще без уровней изоляции, а эта задача куда более жёсткая, чем то, что нужно мне. S>При этом ты путаешь понятия ссылочной целостности и актуальности данных. Печально.
А вот актуальность я не обещал. Без push со стороны сервера это не реально.
L>>>>Например, некоторые параметры не хранятся один-в-один в полях таблицы, а сериализуются в xml-ную колонку. Наличие DAL-а позволяет этот механизм хранения скрыть от бизнеса, что, имхо, очень удобно и позволяет очень просто дополнять поля сущности.
L>>Отсутствие DAL-а, вестимо. Entity-то отличается от схемы данных.
G>От повторения одного и того же оно правдой не становится. В EF маппинг, даже нетривиальный, делается без DAL.
Расскажи, как мне сделать в EF маппинг полей сущности на xml-колонку. С удовольствие послушаю.
Здравствуйте, VladD2, Вы писали:
VD>Я обосновал свое утверждение.
Я тоже.
VD>Ты писал о защите. Я тебе продемонстрировал, что защита весьма мнимая. Чем более сложными вещами ты занимаешься, тем меньше вероятность того, что баги на которые ты напоролся будут устранены майкрософтом.
VD>А что тебе дает лэйбак Майкрософт? В чем защита то? Ты же говорил о вере в том, что МС исправит какие-то там ошибки...
Для тех, кто не читает чужих сообщений, повторю еще раз:
больше вероятность того, что кто-то другой до тебя найдет workaround твоих проблем и опубликует его в интернете.
Где тут хоть слово про исправление майкрософтом ошибок?
Речь о том, что в случае с любой известной и распространенной библиотекой (не обязательно от МС) можно просто набрать в гугле свою проблему и по первой-второй ссылке узнать, как другие пользователи решили эту проблему. Соответственно, чем более экзотическую библиотеку ты используешь, тем больше вероятность того, что тебе самому придется решать твою проблему, тратя на это уйму времени. Отличительной особенностью библиотек от МС является то, что они будут сильно распространены даже если они хреновые.
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>А что в приведенных цитатах есть противоречия?
Противоречие тут в том, что ты утверждаешь, что view лезет в модаль за данными.
В приведенной же цитате говорится, что controller подготавливает эти данные для view, а следовательно ни в какую модель view лезть не должен.
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>Опять же, что ты тут вычитал?
Ни модель, ни представление не должны знать о контроллере.
vs
Each view is associated with a unique controller and vice versa. Instance variables in each maintain this tight coupling.
Как можно не знать о контероллере и при этом иметь ссылку на него?
L>>>>Да все это понятно. Поинт лишь в том, что пихать это в presentation — последнее дело.
VD>>>Что это? Доступ к модели? А куда же его пихать, то?
L>>В контроллер, другого не остается.
VD>Иди и еще раз прочитай задачи контроллера. Если в контроллере будет логика отображения, то это будет смешиванием логики отображения и логики управления, то есть нарушением базового принципа MVC.
Совершенно верно, логике отображения не место в контроллере.
Но только вот формирование запросов к логике отображения не относятся вообще никаким боком. И потому-то им во view и не место.
VD>Короче, в данной теме я не намерен продолжать обсуждение паттерна MVC. Если тебе интересно, заводи новую тему.
Слив засчитан.
L>>>>UI должен быть туп как пробка и не должен содежать ни методов для формирования чего-либо, ни оперировать запросами.
VD>>>Кто сказал такую чушь? Задача представления — отображать данные модели. Какова сложность этого зависит исключительно от двух факторов — сложности представления и сложности модели. Если представление отображает не всю модель целиком, то нужны хорошие инструменты выбрать нужные для отображения данные.
L>>Если подходить формально, то ты прав. А на практеке от кода еще стребуется как минимум тестируемость. Если мы зашиваем часть логики запросов в представление, мы эту возможность теряем.
VD>Интересный поворот. С доказательством нарушения принципов MVC не вышло, переключаемся на тестирование...
Задача view — рендеринг UI и только. Формирование запросов к UI никакого отношения не имеет.
VD>При желании организовать тестирование презентационной логике тоже можно. Но это опять таки очередное отклонение от темы. Главное, что для этого нет нужды выносить презентационную логику из представления.
Презентационную логику ни в коем случае не надо выносить из представления. Выносить оттуда нужно запросы.
L>>Как тогда скрывать детали маппинга? Я кажется, догадываюсь, что ты ответишь. В задницу сокрытие деталей. Оно?
VD>У тебя будут объекты на которые идет отображение. Вот они и будут скрывать все что нужно. Можешь считать их DAL-ом. VD>Мне больше нравится терминология MVC. В ней данные объекты являются публичным интерфейсом модели.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>>>Нет, я не потребовал. Я показал, что кеширование отдельных запросов без преобразования в объекты приводит к несогласованности данных кешах запросов. А вот если собрать граф объектов, то такой несогласованности не будет. G>>Именно эта фраза подтевржадет то что кеш в ORM-системах может быть только глобальный.
A>Ты не прав Вполне можно построить ссылочноцелостное подмножество данных БД, по объёму значительно меньше данныхв БД.
Это называется локальной репликой — далеко не единственный и уж точно не самый эффективный вариант кеширования.
Шорош только тем, что его проще всего построить.
Основной особенностью такого кеша является то, что из него нельзя выделить часть без нрушения работоспособности кеша. Это значит что имеет смысл создавать один глобальный кеш для приложения, а не кешировать локально результаты запроса.
Если еще и хочется запросы делать к кешу, то можно использовать inprocess БД.
G>>Кажестся я уже описывал, что эта задача и другими способами нормально не решается. G>>Вообще если между двумя запросами свзязанных данных проходит какое-то время, то всегда можно нарваться на рассогласованность, и без пессимистичной блокировки этих данных в общем случае победить такое нельзя.
A>Ты опять таки не прав.
Ну а обоснования будут?
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Нет, ты это сам придумал, что объект штата будет большим из-за того, что программа предназначена для работы с географией. C>>>Если программа для работы с географией не предназначена, то раздувание объекта типа "штат" — это плохой дизайн. G>>все что не укладывается в ORM — плохой дизай, ага. C>Ага.
Бред, однозначно.
C>>>Для редких случаев, когда overhead от ORM слишком велик — используем DTO. G>>Нормальные люди используют запросы и не парятся с DTO, ORM и другими трухбуквенными сочетаниями. C>В том числе и с SQL?
В том числе и SQL.
Для запросов Linq подходит лучше, у него побольше средств динамического построения запросов.
C>>>Ситуация примерно как с ассмеблерными вставками раньше — оптимизируем только узкие места. G>>Неверная аналогия. SQL обладает большими возможностями, чем GetById, FindByName и прочее. C>Что ты привязался к FindByName?? В нормальных ORM есть свой язык запросов, кроме того, есть ещё навигационный доступ.
Мы тут говорим не только о выборках, но и о DML.
К сожалению такой возможности покачто нету ни в одном фреймворке.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Лучше более обще опишу: есть выборка, полученная наложением кучи условий, соединений, группировок (неважно каких). G>>В интерфейсе эта выборка используется в двух местах, в каждом из них надо отображать свой набор полей выборки, со своими условиями сортировки. G>>Внимание вопрос: это будет две разные хранимки?
A>it depends. A>Если это отчёт для экспорта в Excel и печати на принтере, то два разных запроса. A>Если это данные которые потенциально могут редактироватся, то скорее всего один запрос. A>Возможно, если сама сущность тяжёлая, например у сотрудника фотография 5 на 6 метров, и тяжёлая часть (фотография) нужна редко, то, возможно, что список сущностей будет загружаться в два этапа. Экономить память и трафик иногда не передавая дату рождения из 8 байт я считаю не разумным.
А теперь без теории.
Мега-генератор хранимок как работает?
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Sinclair, Вы писали:
A>>>У етбя получится очень сложная проверялка ссылочной целостности. S>>При чем тут RI? Она ортогональна безопасности.
A>Я пришёл к выводу, что система безопасности должна обеспечивать ссылочную целостность — я не могу читать объект, который ссылается на объекты, которые я читать не могу.
Если юз-кейсы другие что делать? Переписывать генератор хранимок?
A>>>Я уже насмотрелся как кассир в Батуми принимал деньги от доставки Кутаиси в кассу Телави. Ссылочная целостность прав доступа — очень важная вещь. S>>Непонятно, о чем ты говоришь. Ограничения на то, кто где должен иметь право принимать деньги — это как раз бизнес-логика. И именно ее лучше делать так, как я говорю. A>Вот это-то и есть ошибка, котрую я уже много раз видел — права доступа не на объекты, а на операции.
Это как раз очень правильный подход, который не позволяет случаться конфузам, описанным тобой выше — попытка чтения подграфа связанных объектов, часть из которых доступны пользователю, а часть — нет.
A>Еси делать права доступа на операции, то получится код, проверяющий, что касса, кассир и сдающий деньги числятся за одним и тем же филиалом. Это код и это не гибко.
Какой код? Это установка PrincipalPermisiion на методе.
A>Не гибко, по той простой причине, что если кассу в Телави ограбили, я машины доставки пущу в Тбилиси, благо всего пара часов пути. А чтобы пустить их в Тбилиси мне надо переписывать код проверяющий права доступа.
Неверно. Для этого надо включить пользователя в другую группу.
Для этого администратор даже не дожен знать об объектах и прочей мути.
Вообще RBS для операций подходит для 95% сценариев.
A>Если раздавать права доступа на объекты, то кассир из Батуми другие филиалы вообще не видит. Так как проверка прав доступа обеспечивает ссылочную целостность, он не только филиалы другие не видит, он ещё ин е может оформить на них никакие операции, не может просмотреть отчёты по ним и т.п. То есть я указав права доступа всего на один объект, разрулил проблемы с большим количеством операций. Поменять права — дело пяти минут и работа уже для администратора, а не программиста.
Ты видимо живешь в своей особенной реальности, созданной множеством ошибок при разработке одной программы.
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, gandjustas, Вы писали:
L>>>>>
L>>>>>Например, некоторые параметры не хранятся один-в-один в полях таблицы, а сериализуются в xml-ную колонку. Наличие DAL-а позволяет этот механизм хранения скрыть от бизнеса, что, имхо, очень удобно и позволяет очень просто дополнять поля сущности.
L>>>Отсутствие DAL-а, вестимо. Entity-то отличается от схемы данных.
G>>От повторения одного и того же оно правдой не становится. В EF маппинг, даже нетривиальный, делается без DAL.
L>Расскажи, как мне сделать в EF маппинг полей сущности на xml-колонку. С удовольствие послушаю.
В ssdl можно указать запрос, который получает для получения сущностей (Defining query кажись).
Кроме того в MS SQL 2008 есть sparse columns, которые делают тоже самое, но на уровне БД.
Вообще говоря инкапсуляция на уровне БД гораздо эффективнее и удобнее.
Здравствуйте, gandjustas, Вы писали:
G>Шорош только тем, что его проще всего построить.
А чем плох, не написал.
G>Основной особенностью такого кеша является то, что из него нельзя выделить часть без нрушения работоспособности кеша. Это значит что имеет смысл создавать один глобальный кеш для приложения, а не кешировать локально результаты запроса.
G>Если еще и хочется запросы делать к кешу, то можно использовать inprocess БД.
Кеш может жить не дольше самого приложения.
G>>>Вообще если между двумя запросами свзязанных данных проходит какое-то время, то всегда можно нарваться на рассогласованность, и без пессимистичной блокировки этих данных в общем случае победить такое нельзя. A>>Ты опять таки не прав. G>Ну а обоснования будут?
А чёго это я должен доказывать? Это ты покажи пример где наступает рассогласование. А у меня всё хорошо.
Здравствуйте, gandjustas, Вы писали:
A>>Если это отчёт для экспорта в Excel и печати на принтере, то два разных запроса. A>>Если это данные которые потенциально могут редактироватся, то скорее всего один запрос. A>>Возможно, если сама сущность тяжёлая, например у сотрудника фотография 5 на 6 метров, и тяжёлая часть (фотография) нужна редко, то, возможно, что список сущностей будет загружаться в два этапа. Экономить память и трафик иногда не передавая дату рождения из 8 байт я считаю не разумным. G>А теперь без теории. G>Мега-генератор хранимок как работает?
На практике, так.
Если это отчёт для экспорта в Excel и печати на принтере, то два разных запроса.
Отчёты пока в виде отдельных хранимок и это катастрофа. Я их потихоньку перевожу на Linq. Буду его использовать только для отчётов. Провайдер Linq свой.
Если это данные которые потенциально могут редактироватся, то скорее всего один запрос.
Возможно, если сама сущность тяжёлая, например у сотрудника фотография 5 на 6 метров, и тяжёлая часть (фотография) нужна редко, то, возможно, что список сущностей будет загружаться в два этапа. Экономить память и трафик иногда не передавая дату рождения из 8 байт я считаю не разумным.
Генератор умеет разбивать объект на два куска — маленький грузящийся всегда и большой грузящийся по требованию. Как разбивать решает программист.
Здравствуйте, gandjustas, Вы писали:
A>>Я пришёл к выводу, что система безопасности должна обеспечивать ссылочную целостность — я не могу читать объект, который ссылается на объекты, которые я читать не могу. G>Если юз-кейсы другие что делать? Переписывать генератор хранимок?
А нет других юз-кейзов Переписывать генератор не надо, можно менять права доступа.
A>>Вот это-то и есть ошибка, котрую я уже много раз видел — права доступа не на объекты, а на операции. G>Это как раз очень правильный подход, который не позволяет случаться конфузам, описанным тобой выше — попытка чтения подграфа связанных объектов, часть из которых доступны пользователю, а часть — нет.
Я на этот очень правильный подход уже насмотрелся — он хорош в теории и, быть может, в лабе. На практике от него одни проблемы.
A>>Не гибко, по той простой причине, что если кассу в Телави ограбили, я машины доставки пущу в Тбилиси, благо всего пара часов пути. А чтобы пустить их в Тбилиси мне надо переписывать код проверяющий права доступа. G>Неверно. Для этого надо включить пользователя в другую группу.
Нельзя, он тогда должен быть сразу в двух группах-филиалах.
A>>Если раздавать права доступа на объекты, то кассир из Батуми другие филиалы вообще не видит. Так как проверка прав доступа обеспечивает ссылочную целостность, он не только филиалы другие не видит, он ещё и не может оформить на них никакие операции, не может просмотреть отчёты по ним и т.п. То есть я указав права доступа всего на один объект, разрулил проблемы с большим количеством операций. Поменять права — дело пяти минут и работа уже для администратора, а не программиста. G>Ты видимо живешь в своей особенной реальности, созданной множеством ошибок при разработке одной программы.
А ты всё никак не приведёшь контрпримеры. А ошибки не мои, это Microsoft Dynamics NAV, например. Часто бывало что операцию запретишь, а её всё равно можно через другое окно сделать.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Шорош только тем, что его проще всего построить. A>А чем плох, не написал.
Плох тем, что требует достаточно много приседаний для синхронизации.
G>>Основной особенностью такого кеша является то, что из него нельзя выделить часть без нрушения работоспособности кеша. Это значит что имеет смысл создавать один глобальный кеш для приложения, а не кешировать локально результаты запроса. G>>Если еще и хочется запросы делать к кешу, то можно использовать inprocess БД. A>Кеш может жить не дольше самого приложения.
С чего бы?
Вот Янус и почта так работает.
G>>>>Вообще если между двумя запросами свзязанных данных проходит какое-то время, то всегда можно нарваться на рассогласованность, и без пессимистичной блокировки этих данных в общем случае победить такое нельзя. A>>>Ты опять таки не прав. G>>Ну а обоснования будут?
A>А чёго это я должен доказывать? Это ты покажи пример где наступает рассогласование. А у меня всё хорошо.
Еще раз. Я (и не только) говорю что сохранить согласованность данных между двумя запросами в общем случае можно только используя транзакционные методы (блокировки).
Ты так и не смог доказать обратного. Частные случаи, вероятности и отстраненные размышения мало интересуют.
A>>>Вот это-то и есть ошибка, котрую я уже много раз видел — права доступа не на объекты, а на операции. G>>Это как раз очень правильный подход, который не позволяет случаться конфузам, описанным тобой выше — попытка чтения подграфа связанных объектов, часть из которых доступны пользователю, а часть — нет. A>Я на этот очень правильный подход уже насмотрелся — он хорош в теории и, быть может, в лабе. На практике от него одни проблемы.
И какие проблемы?
A>>>Не гибко, по той простой причине, что если кассу в Телави ограбили, я машины доставки пущу в Тбилиси, благо всего пара часов пути. А чтобы пустить их в Тбилиси мне надо переписывать код проверяющий права доступа. G>>Неверно. Для этого надо включить пользователя в другую группу. A>Нельзя, он тогда должен быть сразу в двух группах-филиалах.
В RBS членство в нескольких группах — нормальное явление.
A>>>Если раздавать права доступа на объекты, то кассир из Батуми другие филиалы вообще не видит. Так как проверка прав доступа обеспечивает ссылочную целостность, он не только филиалы другие не видит, он ещё и не может оформить на них никакие операции, не может просмотреть отчёты по ним и т.п. То есть я указав права доступа всего на один объект, разрулил проблемы с большим количеством операций. Поменять права — дело пяти минут и работа уже для администратора, а не программиста. G>>Ты видимо живешь в своей особенной реальности, созданной множеством ошибок при разработке одной программы.
A>А ты всё никак не приведёшь контрпримеры. А ошибки не мои, это Microsoft Dynamics NAV, например. Часто бывало что операцию запретишь, а её всё равно можно через другое окно сделать.
Отсуствие тестирования и кривость рук разработчиков теперь будем лечить введением row-level security?
Кроме всего прочего RBS позволяет описывать гораздо больше сценариев, чем row-level security.
Пример Синклера: "Младший менеджер не имеет права отгружать заявку дороже 50000р без подтверждения старшего менеджера" отлично описывается в RBS, и нифига не работает в варианте row-level security.
Здравствуйте, gandjustas, Вы писали:
A>>Кеш может жить не дольше самого приложения. G>С чего бы? G>Вот Янус и почта так работает.
Может в смысле may, а не can.
A>>А чёго это я должен доказывать? Это ты покажи пример где наступает рассогласование. А у меня всё хорошо. G>Еще раз. Я (и не только) говорю что сохранить согласованность данных между двумя запросами в общем случае можно только используя транзакционные методы (блокировки). G>Ты так и не смог доказать обратного. Частные случаи, вероятности и отстраненные размышения мало интересуют.
Ты (и не только) говорите глупость. Нельзя обеспечить актуальность и согласованность. Согласованность обеспечить можно.
Если нам не помогут, то мы тоже никого не пощадим.
.
