Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>Чтобы такое можно было сделать каждый объект должен уметь отавать описание валидации. G>>Этого можно добиться двумя способами: а)интерфейсом, но тогда надо корректно инстанцировать это описание, ведь объект может создаваться явно, через конструктор, и неявно — маппером. б)внешним описанием — атрибутами, xml или чем-то еще и получать это описание по некоторому индентификатору, которым обладает объект (самое простое — по типу). G>>Самим процессом валидации объекта по соответствующему описанию должен заниматься какой-то сервис.
G>>Вот и получается что валидацией знаимается внешний сервис, а не сама сущность. Можно кончено обязанность валидации сущности повесить на саму сущность и делегировать процесс сервису, но получаем теже проблемы с получением ссылки на сервис в различных условиях.
T>Какие проблемы, если валидатор получаем например по типу сущности?
Такие что валидация в конечнои итоге может зависить не только от типа сущности. См валидацию zipCode.
G>>А также приседания при необходимости отключить валидацию и прочее. T>Не надо ее отключать.
Не смешите.
Сами писали
У нас у таких сущностей есть состояние Draft. В этом состоянии проверки не делаются, т.е. фактически она работает как data object. После завершения инициализации сущность переходит в состояние Ready (с валидацией). Переход обратно невозможен.
Даже вот это
G>Кстати, при наличии CountryCode внутри кастомера невозжножно будет поменять этот самый CountryCode, потому что сразуже станет невалидным ZipCode (ну если у них случано не совпадут правила валидации).
Можно, через метод, меняющий CountryCode и Zip.
является примером временного отключения валидации, в какой-то момент внутри метода сущность перестанет быть валидной.
Здравствуйте, gandjustas, Вы писали:
T>>Замени "ER модель" на сущности domain model, а "валидация модели" — на constraint-ы
G>И что от этого изменится. Указанные выше 4 пунтка как были ортогональны друг другу, так и останутся.
Пункты ортогональны, но в программную модель они лягут по другому
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>Замени "ER модель" на сущности domain model, а "валидация модели" — на constraint-ы
G>>И что от этого изменится. Указанные выше 4 пунтка как были ортогональны друг другу, так и останутся.
T>Пункты ортогональны, но в программную модель они лягут по другому
По какой причние?
Указанные пункты отлично ложатся на код с тойже степенью ортогональности.
Здравствуйте, gandjustas, Вы писали:
T>>Какие проблемы, если валидатор получаем например по типу сущности? G>Такие что валидация в конечнои итоге может зависить не только от типа сущности. См валидацию zipCode.
С zip-ом вообще в конце концов выяснили, что он не влияет на валидность кастомера, а является пред-условием отгрузки.
G>>>А также приседания при необходимости отключить валидацию и прочее. T>>Не надо ее отключать. G>Не смешите. G>Сами писали G>
G>У нас у таких сущностей есть состояние Draft. В этом состоянии проверки не делаются, т.е. фактически она работает как data object. После завершения инициализации сущность переходит в состояние Ready (с валидацией). Переход обратно невозможен.
Это состояние сущности, не искусственно введенное для отключения валидации, а отдельное состояние.
G>Даже вот это G>
G>>Кстати, при наличии CountryCode внутри кастомера невозжножно будет поменять этот самый CountryCode, потому что сразуже станет невалидным ZipCode (ну если у них случано не совпадут правила валидации).
G>Можно, через метод, меняющий CountryCode и Zip.
G>является примером временного отключения валидации, в какой-то момент внутри метода сущность перестанет быть валидной.
Это внутренняя реализация, с точки зрения стороннего наблюдателя инварианты сохраняются.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>Какие проблемы, если валидатор получаем например по типу сущности? G>>Такие что валидация в конечнои итоге может зависить не только от типа сущности. См валидацию zipCode.
T>С zip-ом вообще в конце концов выяснили, что он не влияет на валидность кастомера, а является пред-условием отгрузки.
Это в одной конкретной модели, но кастомеры могут в разных моделях.
G>>>>А также приседания при необходимости отключить валидацию и прочее. T>>>Не надо ее отключать. G>>Не смешите. G>>Сами писали G>>
G>>У нас у таких сущностей есть состояние Draft. В этом состоянии проверки не делаются, т.е. фактически она работает как data object. После завершения инициализации сущность переходит в состояние Ready (с валидацией). Переход обратно невозможен.
T>Это состояние сущности, не искусственно введенное для отключения валидации, а отдельное состояние.
Опять вспоминаем кастомера и его zipCode.
G>>Даже вот это G>>
G>>>Кстати, при наличии CountryCode внутри кастомера невозжножно будет поменять этот самый CountryCode, потому что сразуже станет невалидным ZipCode (ну если у них случано не совпадут правила валидации).
G>>Можно, через метод, меняющий CountryCode и Zip.
G>>является примером временного отключения валидации, в какой-то момент внутри метода сущность перестанет быть валидной.
T>Это внутренняя реализация, с точки зрения стороннего наблюдателя инварианты сохраняются.
А если сторонний наблюдатель в другом потоке?
Здравствуйте, gandjustas, Вы писали:
T>>>>Какие проблемы, если валидатор получаем например по типу сущности? G>>>Такие что валидация в конечнои итоге может зависить не только от типа сущности. См валидацию zipCode.
T>>С zip-ом вообще в конце концов выяснили, что он не влияет на валидность кастомера, а является пред-условием отгрузки. G>Это в одной конкретной модели, но кастомеры могут в разных моделях.
Какие разные модели уже? Откуда они взялись?
T>>Это состояние сущности, не искусственно введенное для отключения валидации, а отдельное состояние. G>Опять вспоминаем кастомера и его zipCode.
Опять читаем коммент выше и забываем про zip
T>>Это внутренняя реализация, с точки зрения стороннего наблюдателя инварианты сохраняются. G>А если сторонний наблюдатель в другом потоке?
А если между моментом, когда был вызван ваш сервис, и до момента, когда была вызвана реализация, кто-то прочитает значение из другого потока?
Не усложняй, не надо тут приплетать еще и другой поток.
Здравствуйте, Tissot, Вы писали:
T>Опять хамишь. Ты что, без этого совсем не можешь?
А как ты ждешь, чтобы на твое хамство отвечали?
T>Слышал конечно (зевок). Я же тебе же отвечал, что я не со школьной скамьи сюда пришел.
Меня терзают смутные сомнения.
T>Слушай, у меня от твоих слов мозг начинает плавиться. Зачем ты тогда писал T>
T>добавляя новое поведение, надо его просто добавлять, а не менять старое
T>, если какая-то часть исходников все-таки трогается.
Что тебе в этой фразе не понятно?
T> Данные как раз мы не защищаем, а наоборот выставляем напоказ.
Нет, именно что защищаем. Ознакомься еще раз с тем, что такое инкапсуляция.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали: T>>>Пункты ортогональны, но в программную модель они лягут по другому G>>По какой причние? T>Потому что инвариант.
G>>Указанные пункты отлично ложатся на код с тойже степенью ортогональности. T>Не очень. Как защитить инварианты? T>Пока что кроме договоренности о том, что изменений надо вызвать валидацию, ничего не было предложено.
Какие инварианты? В анализе инвариантов не было. Достаточно чтобы модель соответствовала бизнес-правилам до и после завершения бизнес-операций. Фактически необходима транзакционная целостность модели для бизнес-операций. Что происходит внутри транзакции с точки зрения анализа неважно.
Кроме того в бизнесе даже не все бизнес-правила являются строгими.
Например остатки в учетных системах важно проверять на конец отчетного периода, а не при каждой операции.
То что нужны инварианты в классах данных, которые вроде как обеспечивают целостность всей операции, это уже вы сами придумали. Даже у фаулера такого нету.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>>>Какие проблемы, если валидатор получаем например по типу сущности? G>>>>Такие что валидация в конечнои итоге может зависить не только от типа сущности. См валидацию zipCode.
T>>>С zip-ом вообще в конце концов выяснили, что он не влияет на валидность кастомера, а является пред-условием отгрузки. G>>Это в одной конкретной модели, но кастомеры могут в разных моделях.
T>Какие разные модели уже? Откуда они взялись?
Например система, которая занимается почтно (обычной бумажной). Все кастомеры имеют zip, кастомеры расположены в разных регионах, каждый регион в какой-то стране.
Вот вам пример. Таких моделей миллион.
Валидация zip зависит от страны региона. Как вы в таком случае обеспечите валидность zipCode в каждый момент времени в многопользовательской системе?
T>>>Это внутренняя реализация, с точки зрения стороннего наблюдателя инварианты сохраняются. G>>А если сторонний наблюдатель в другом потоке?
T>А если между моментом, когда был вызван ваш сервис, и до момента, когда была вызвана реализация, кто-то прочитает значение из другого потока?
Если не пытаться постоянно сохранять "валиднось" по абсолютно пофиг кто и сколько раз чего читает и пишет. Конкурентную запись данных разраливает БД, перед записью данные будут провалидированы.
T>Не усложняй, не надо тут приплетать еще и другой поток.
С учетом тенденций развития железа стоит каждую программу рассматривать с позиции распараллеливания.
Здравствуйте, Tissot, Вы писали: T>Концептуальная модель.
А что такое "концептуальная модель"? Где ее определение?
Замечу, что ты как-то плавно съехал с утверждения "доменная модель должна быть максимально приближена к предметной области" к "доменная модель должна соответствовать концептуальной модели". Со вторым никто не спорил, особенно если учесть, что концептуальная модель вообще только что внезапно появилась в обсуждении.
T>Не забывай, что DACL — это не только пользователи, но и группы. Вот как раз по кастомерам пользователи и группируются. Я же специально написал "ассоциированный с указанным кастомером"
Вот пока что непонятно, что означает "указанный кастомер". К тому же, пока что никаких групп не возникло. Есть упоминания про склад, про кастомеров, про пользователей, которые как-то проассоциированы с кастомером.
Группе пользователей пока что в пмире ничего не соответствует.
T>А что ты от меня хотел бы услышать? Формат оформления документов? В этом я увы не силен.
При чем здесь формат? Просто если мы прожолжим в том же духе, то всё сведется к утверждению типа "код приложения должен делать то, что должен делать код приложения, по мнению системного аналитика". Что, очевидно, никак не годится для аргументации той или иной архитектуры.
T>Прочитал: "HTTP/1.1 403 Access Denied." Действительно, просветление снизошло.
Прикольно. Только что закрыли. Попробуй порыть в кэше гугла.
T>Продолжаю повторять — сохранение инвариантов.
Пока что никаких инвариантов, невыразимых настройками банальной ER-модели, не прозвучало.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
T>>Концептуальная модель. S>А что такое "концептуальная модель"? Где ее определение?
S>Замечу, что ты как-то плавно съехал с утверждения "доменная модель должна быть максимально приближена к предметной области" к "доменная модель должна соответствовать концептуальной модели". Со вторым никто не спорил, особенно если учесть, что концептуальная модель вообще только что внезапно появилась в обсуждении.
Для меня предметная область и есть результат анализа. Разве это не для всех так?! Тады ой.
T>>Не забывай, что DACL — это не только пользователи, но и группы. Вот как раз по кастомерам пользователи и группируются. Я же специально написал "ассоциированный с указанным кастомером" S>Вот пока что непонятно, что означает "указанный кастомер". К тому же, пока что никаких групп не возникло. Есть упоминания про склад, про кастомеров, про пользователей, которые как-то проассоциированы с кастомером. S>Группе пользователей пока что в пмире ничего не соответствует.
Соответствует — пользователи, относящиеся к этому кастомеру.
T>>А что ты от меня хотел бы услышать? Формат оформления документов? В этом я увы не силен. S>При чем здесь формат? Просто если мы прожолжим в том же духе, то всё сведется к утверждению типа "код приложения должен делать то, что должен делать код приложения, по мнению системного аналитика". Что, очевидно, никак не годится для аргументации той или иной архитектуры.
Годится. Программная архитектура — это то, что следует ЗА анализом, не перед.
T>>Прочитал: "HTTP/1.1 403 Access Denied." Действительно, просветление снизошло. S>Прикольно. Только что закрыли. Попробуй порыть в кэше гугла.
Ок
T>>Продолжаю повторять — сохранение инвариантов. S>Пока что никаких инвариантов, невыразимых настройками банальной ER-модели, не прозвучало.
Где-то из подветок писал, что при закрытии кастомера должны быть закрыты соотвтствующие equipment-ы. Это вполне себе констрейнт.
Здравствуйте, Tissot, Вы писали: T>Для меня предметная область и есть результат анализа.
Ок. А что тогда является предметом анализа? T> Разве это не для всех так?! Тады ой.
Не, не для всех. Для большинства предметная область — это собственно прообраз, который мы анализируем. Не обязательно это будет именно "реальный мир", в том смысле, что, к примеру, бухгалтерия к реальному миру никакого отношения не имеет, но тем не менее она является полноценной предметной областью.
Отсюда понятно, что предметная область не может быть результатом анализа. Ты же не думаешь, что бухгалтерия — все эти планы счетов, проводки, актив/пассив и прочие понятия — возникает из небытия только тогда, когда архитектор 1с берется за дело?
Нет, она существует совершенно отдельно от софта.
T>Соответствует — пользователи, относящиеся к этому кастомеру.
Ну вот еще. Пока что нет повода генерализовывать пользователей "относящихся к кому-то" до группы пользователей вообще.
T>Годится. Программная архитектура — это то, что следует ЗА анализом, не перед.
Продолжаю непонимать, что же именнол следует "перед" анализом. Пока что все понятия, которые ты вводишь, у тебя являются результатом анализа.
Я насчитал уже три: "концептуальная модель", "предметная область", "программная архитектура".
Ты не мог бы расшифровать своё понимание этих понятий и их взаимосвязь? А также пояснить, к чему именно должна быть близка "доменная модель" как подвид "программной архитектуры".
Это я к тому, что, вообще говоря, любая архитектура будет близкой к соответствующему результату анализа.
А какая именно — зависит только от способа, которым анализ проводить. К примеру, если мы анализируем проблему с точки зрения ФП, то у нас модель предметной области будет содержать исключительно функции различных порядков. Если применить OOD, то получим объектную модель. Если применить реляционную алгебру, то получим ER-модель. Естественно, реализующая это архитектура будет максимально приближена к построенной модели.
S>>Пока что никаких инвариантов, невыразимых настройками банальной ER-модели, не прозвучало. T>Где-то из подветок писал, что при закрытии кастомера должны быть закрыты соотвтствующие equipment-ы. Это вполне себе констрейнт.
Что характерно, он не является инвариантом . Это постусловие для некоторого действия. Причем замечу, что оно несводимо к ограничениям уровня объекта, т.к. включает в себя несколько объектов. Более того, это скорее наше определение операции "закрытия кастомера".
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>А какая именно — зависит только от способа, которым анализ проводить. К примеру, если мы анализируем проблему с точки зрения ФП, то у нас модель предметной области будет содержать исключительно функции различных порядков. Если применить OOD, то получим объектную модель. Если применить реляционную алгебру, то получим ER-модель. Естественно, реализующая это архитектура будет максимально приближена к построенной модели.
Комплексный подход конечно сложнее и запутанней, но результаты получаются имхо поинтереснее
Здравствуйте, alvas, Вы писали:
VD>>напрашивающиеся для LINQ insert, update и delete. Жаль, что, в отличие от Nemerle, такие языки, как C# и VB, не позволяют расширить свой синтаксис чтобы бесшовно ввести эти операторы в язык. Но хотя бы в виде процедур, принимающих условия в виде деревьев выражений, их можно добавить в любой язык. Продаю идею .
A>Планируется ли добавление в Nemerle insert, update и delete?
Да. Но скорее всего это так и останется расширением доступным только для немерлистов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tissot, Вы писали:
T>Нет, сам по себе подход не может быть "вредным и не нужным". Всегда нужно обосновывать почему он вреден и чем он лучше существующих подходов.
Так не может быть "вредным и не нужным" или требуется это обосновывать? Ты уж определись.
VD>>Наличие (в LINQ to SQL и EF) возможности это делать (обрабатывать объекты императивно) — есть отход от декларируемой идеологии, что есть несомненной (для меня) зло.
T>А можно ссылку на информацию о том, что ER-подход был когда-либо продекларирован командой ADO.NET.
Читать над больше. Это не раз говорилось. К тому же даже названия технологий "LINQ to SQL" и "LINQ to Entity" говорят сами за себя.
Я всегда считал, что они делают O/R Mapper, а тут оказывается такое.
Ты бы читал внимательно что написано, тогда не пришлось бы тебе по сто раз повторять одно и то же.
Еще раз. O/R Mapper не имеет никакого отношения к идеям персистентности объектов. Так что ничего не мешает создавать O/R Mapper основанный на на них, а на ER-модели. Все что делают O/R Mapper-ы — это отображают сущности БД на типы в прграмме.
VD>>В то же время отсуствие декларативных средств обработки данных в стиле insert, update и delete просто не оставляет шансов не использовать иделогию противоречащую ER-идеологии.
VD>>Потом это твое высказывание вообще-то само по себе требует доказательства.
T>Которое высказывание требует доказательства?
Вот это:
Мне кажется, при обсуждении технологий нельзя утверждать что что-то должно быть сделано именно так, без упоминания зачем это должно быть сделано именно так, без обсуждения преимуществ предложенного подхода. Если вы со мной согласны, не могли бы вы описать, в чем преимущество такого подхода?
Весьма спорное, и я бы даже сказал, странное утверждение.
T>>>Увы не стало бы.
VD>>С чего бы это?
T>Потому что реляционные операторы это — объединение, пересечение, разность, произведение, сокращение, проекция, соединение, деление. Другие в реляционную алгебру не входят.
Нельзя жить так буквально. Update, delete и insert делают тоже самое, но с учетом некоторых особенностей СУБД.
В общем, тебе яно хочется уйти от темы и поспорить с деталями.
По делу что-то хочешь сказать? Другими словами — какие у тебя имеются претензии к предложению ввести в LINQ операторы update, delete и insert?
T>Не понимаю, чем код customer.Name = "XXX"; ctx.SubmitChangs(); менее декларативен, чем update customer set Name = "XXX" where customer.id = 123 ?
Тем что нельзя написать скажем:
update customer set some = 123 where customer.Name = "XXX";
Я уже не говрю, о вариантах с подзапросами и соеденениями нескольких сущностей.
Ну, а то что ты не понимаешь и является отличным доказательством того тезиса, что Корба, ЁДжиБи и прочие Гибернэйты отлично отшлифовали мозг большой части программистов. И та теперь уже и мыслить иными категориямти не может.
VD>>Хочется задать встречный вопрос. Ты серьезно считашь, что обработка данных в императивном стиле, в виде объектов лучше? Если да, то попробуй обосновать это. Если нет, то опиши вариант который ты считашь лучшим.
T>Я считаю этот вопрос стоит разделить на 2: T>1) ER vs ObjectModel: мой выбор однозначно в пользу ObjectModel. Потому что она банально предоставляет больше возможностей. Кроме того, er может быть смоделирована через object model, обратное — неверно.
Где в объектной модели понятие "связи" (relation)?
Как эффективно преобразовать изменение объектного графа в изменениие таблиц БД?
Утверждение о том, что объектная модель более гибка нежели ER в обще-о верно. Но гибкость определяется тем, что модель эта была предназначена для представления объектны графов в памяти, не данных в БД.
Так что именно эта гибкость и становится проблемой. По ER-модели же можно легко создать адекватную ОО-медель. Эта модель не будет иметь возможности оперировать всеми ОО-принципами и подходами, но для обработки данных этого и не надо. Зато управлять данными становится просто и можно делать это эффективно.
T>2) SQL DML vs unit of work: unit of work в большинстве случаев удобнее и предпочтительнее.
Офтоп: Господи, какая ужасная терминология. Русскими словами это выразить нельзя?
Попробуй обосновать свои заблуждения. Продемонстрируй мне хотя бы один пример где DML (в твоей терминалогии) окажется менее понятным, более громоздким и вообще хоть как-то менее удобным нежели делающий тоже самое императивый код. Уверен, что у тебя ничего не удастся.
T>Единственный его недостаток — это когда нужно массово обновить большое количество объектов. В этом случае все объекты приходится тащить из базы, менять их в коде и сабмитить обратно. Это дико неэффективно. Для таких случаем было бы неплохо иметь возможность запускать DML непосредственно из кода. Как LINQ2SQL, так и EF такую возможнось имеют.
Чушь изволите говорить. Ни LINQ to SQL ни EF использовать DML не позволяют.
К тому же использование запросов эффективнее даже при единичном обновлении, так как не требуется предварительно вытаскивать данные объекта на клиента (или можно вытащить только нужные данные и за один прием).
Учитывая, что запросы обеспечивают:
1. Большую компактность и понятность кода.
2. Лучшую стратегию манипулирования данными, что позволяет добиться более высокой производительности.
3. Более высокий уровень обработки даных (отсутствие императивной составляющей).
то не ясно зачем вообще связываться в подходом проигрывающим во всех случаях.
Scope?
VD>>Более явным может быть объявление транзакции. Что-то вроде: VD>>
VD>>using (myDb.BeginTran())
VD>>{
VD>> insert into myDb.TableA values(1, 2, "test");
VD>> delete from myDb.TableA where Col1 = 2;
VD>>}
VD>>
Ты покажи весь код. Где у тебя связь с контекстом?
Потом что будешь делать если у тебя нужно использовать один "объект" в двух транзакциях одновременно? Как это будет выглядеть.
VD>>Стоит. Я уже молчу об эффективности и удобстве.
T>А ты не молчи, ты расскажи.
А что тут рассказывать то? Тот кто умеет писать что-то более высокоуровневое нежели нагромаждение if-ов и циклов, тот и сам это прекрасно понимает.
Ты с sql много работал?
VD>>Болезнь какая-то. Одно упоминание Nemerle и у человека истерика.
T>Да не, я серьезно. Хорошо, когда есть техническая возможность включить такого рода функциональность в язык.
Да, не плохо. Но в данном случае речь не о нем.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Tissot, Вы писали:
T>Я не знал, что если в батче содержится несколько стейтментов, то сервер анализирует весь батч целиком. Всегда был уверен, что он выполняет стейтмент за стейтментом. T>Если у вас другая информация, не мог бы ты подилиться источником оной?
Если речь идет об изменении полей одной таблицы, то всегда можно написать один запрос производящий все нужные вычисления и обновляющий данные. А такой запрос как раз будет отлично оптимизироваться.
В прочем, господа, вы в очередной раз уходите от темы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>В Unit of Work чтение — это обращение к объектам. Причем выполняется оно в две фазы: S>1. Подъем объектов в память (в этот момент работает select) S>2. Обращение к свойствам объектов. S>Как правило, операция №1 настолько дорога, что ее выполняют через кэш. Кэширование на корню убивает возможность автоматической блокировки прочитанных объектов. Поэтому для обеспечения целостности приходится делать дополнительные приседания. Например, вручную блокировать интересующие объекты.
S>Конечно, можно обойтись и без кэша. Но тогда ситуация будет достаточно малоприятной для unit of work из-за просада производительности. S>Теоретически, можно было бы трассировать и операции №2, аналогично тому, как это делается для отслеживания модификаций. Но на практике я такого не встречал. Смею полагать, что тоже по соображениям производительности.
Что касается блокировок, то селекты обеспечивают их не во всех случаях. Фактически полной гарантии можно добиться только при использовании верхнего уровня изоляции, что само по себе снижает эффективность. Но есть простые приемы позволяющие добиться блокировки при исползовании SQL DML. Например, меня "в детстве" учили, что получать значение счетчика надо не так (гипотетический LINQ DML):
var counter = select counter from table where id = 123;
counter++;
update table set table.counter where id = 123;
а так:
update table set counter where id = 123;
select counter from table where id = 123;
При этом запись будет заблокирована первым выражением и второй выражение вернет всегда верное значение. Блокировка же будет снята во время комита.
Более того мы можем проанализировать измененное значение и если что откатить транзакцию.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Мы уже победили, просто это еще не так заметно...
. Это постусловие для некоторого действия. Причем замечу, что оно несводимо к ограничениям уровня объекта, т.к. включает в себя несколько объектов. Более того, это скорее наше определение операции "закрытия кастомера".
