коллеги у меня когнитивный диссонанс или просто шок
разрабы МФОшной проги в ОбработкаПроведения легко и играючи проводят/записывают другой документ !!!
я с 2010 года считал, что ТАК НЕЛЬЗЯ делать )))))
Процедура ОбработкаПроведения(Отказ, РежимПроведения)
СформироватьДвиженияДокумента();
Движения.Записать();
Если ЗначениеЗаполнено(РКОВозвратВознаграждения) и НЕ РКОВозвратВознаграждения.Проведен Тогда
РКООбъект=РКОВозвратВознаграждения.ПолучитьОбъект();
Попытка
РКООбъект.Записать(РежимЗаписиДокумента.Проведение);
Исключение
Отказ = Истина;
КонецПопытки;
КонецЕсли;
Показатьразрабы МФОшной проги в ОбработкаПроведения легко и играючи проводят/записывают другой документ !!!
я с 2010 года считал, что ТАК НЕЛЬЗЯ делать )))))
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
считал
Ну мало ли кто что считает. Есть принцип - АСИД. Атомарность, консистентность, дурабилитии, и что-то там про "И" - хз, забыл. Но атомароность - и консистентность - это как раз про то, что если у тебя меняется что-то зависимое, то оно обязано быть изменено в ходе одной атомарной транзакции, а не двух разных, тогда обеспечивается та самая консистентность, т.е. непротиворечивость данных. А исключении, конечно, по хорошему надо написать про то, что за ошибка произошла. Предположу, что об этом, конечно, пишет документ, который пытаются провести. В остальном какие именно претензии к коду?
(17)
ACID - это про сами транзакции, а не про изменения зависимых объектов одной/несколькими транзакциями :)
Но атомароность - и консистентность - это как раз про то, что если у тебя меняется что-то зависимое, то оно обязано быть изменено в ходе одной атомарной транзакции, а не двух разных, тогда обеспечивается та самая консистентность, т.е. непротиворечивость данных.
ACID - это про сами транзакции, а не про изменения зависимых объектов одной/несколькими транзакциями :)
(26)
Кстати, простое логирование - ему консистентность не нужна, ему важна доступность, поэтому блокировать таблицу при записи нет необходимости. Из-за этого с логированием в 1С все не очень хорошо, т.к. его реализуют часто на как раз такой таблице. При том все поля лога часто есть ключ, что совсем хрень.
ACID продолжает работать для данных?
В то части, которая завязана на СУБД - да, только нужен ли он при таком раскладе? Если много систем будут писать в эту таблицу данные, то никакой разницы нет, в какой последовательности они записаны, если нет необходимости в исторической информации. Т.е. если в каждую следующую строку таблицы не пишется результат выполнения функции над предыдущими. И при конкурентном доступе как раз и создается предпосылка для теоремы САР, в которой то самое "выберите любые два" (из трех). Выбирая согласованность мы теряем доступность или "устойчивость к фрагментации" (что бы это ни значило). Выбирая доступность, выбираем между консистентностью и отсутствием фрагментации. Т.е. если мы хотим соблюсти канон АСИД, мы или блокируем - читаем - считаем - пишем - освобождаем, тем самым существенно теряя в доступности, либо создаем кучу независимых фрагментов, нуждающихся в синхронизации, т.к. пока мы там что-то считали, данные уехали, поэтому создается версия, которая потом имплементируется куда-то как-то, что вообще сложно, зато консистентность...
Кстати, простое логирование - ему консистентность не нужна, ему важна доступность, поэтому блокировать таблицу при записи нет необходимости. Из-за этого с логированием в 1С все не очень хорошо, т.к. его реализуют часто на как раз такой таблице. При том все поля лога часто есть ключ, что совсем хрень.
(1)
1. Попытка исключение скрывает сообщение об ошибке и не мешает поймать "В данной транзакции уже происходили ошибки"
2. Не понятно, что делать с РКООбъект в случае, если идет отмена проведения "основного документа".
3. Вероятно, получаем сакральное знание, что РКОВозвратВознаграждения можно провести просто так, можно из другого документа, можно распровести просто так, не обращая внимания на состояние "родительского" документа.
4. Нарушается принцип слабой связанности, что может аукнуться самым неприятным образом.
Если, например, проведение РКОВозвратВознаграждения потребует дополнительных действий и данных.
Или элементарно станет достаточно долгим (не говоря уж про возможную конкуренцию за ресурсы).
Или ему запретят проведение закрытым периодом и еще много разных "или".
5. Я со свечкой не стоял, но похоже идея была в том, чтобы, не приходя в сознание, все сделать быстро и сдать.
Потому как ответ на вопрос "а как правильно" потребовал бы дотошно разобраться, с вопросом "а зачем вообще нужно такое поведение".
Ключевое слово тут "дотошно", а не "ну у нас тут родительский документ провелся, поэтому надо бы провести дочерний, и нет, почему его не надо в таком случае перепроводить мы вам не скажем" и т.п.
Такое поведение, за исключением "попытка исключение", допустимо для обработки формирования пакета документов в единой транзакции.
В вашем же случае, это явная архитектурная ошибка. Причем чем большими "предохранительными" проверками, она обвязана, тем худшая.
Попытка
РКООбъект.Записать(РежимЗаписиДокумента.Проведение);
Исключение
Отказ = Истина;
КонецПопытки;
РКООбъект.Записать(РежимЗаписиДокумента.Проведение);
Исключение
Отказ = Истина;
КонецПопытки;
1. Попытка исключение скрывает сообщение об ошибке и не мешает поймать "В данной транзакции уже происходили ошибки"
2. Не понятно, что делать с РКООбъект в случае, если идет отмена проведения "основного документа".
3. Вероятно, получаем сакральное знание, что РКОВозвратВознаграждения можно провести просто так, можно из другого документа, можно распровести просто так, не обращая внимания на состояние "родительского" документа.
4. Нарушается принцип слабой связанности, что может аукнуться самым неприятным образом.
Если, например, проведение РКОВозвратВознаграждения потребует дополнительных действий и данных.
Или элементарно станет достаточно долгим (не говоря уж про возможную конкуренцию за ресурсы).
Или ему запретят проведение закрытым периодом и еще много разных "или".
5. Я со свечкой не стоял, но похоже идея была в том, чтобы, не приходя в сознание, все сделать быстро и сдать.
Потому как ответ на вопрос "а как правильно" потребовал бы дотошно разобраться, с вопросом "а зачем вообще нужно такое поведение".
Ключевое слово тут "дотошно", а не "ну у нас тут родительский документ провелся, поэтому надо бы провести дочерний, и нет, почему его не надо в таком случае перепроводить мы вам не скажем" и т.п.
Такое поведение, за исключением "попытка исключение", допустимо для обработки формирования пакета документов в единой транзакции.
В вашем же случае, это явная архитектурная ошибка. Причем чем большими "предохранительными" проверками, она обвязана, тем худшая.
1с это чисто прикладная система. Ее единственная цель - работать как нужно клиенту (выдавать правильный результат) за минимальную цену. Вот если она неправильный результат получает - то так нельзя делать. Если правильно работает - можно. Другие критерии все фальшивые и бессмысленные.
Вот и получается, что из-за возможности клинча не рекомендуют в ОбработкаПроведения не вызывать проведение/запись других документов.
А раз разрабы МФОшной проги это делают, значит они уверены в отсутствии возникновения клинча.
А раз разрабы МФОшной проги это делают, значит они уверены в отсутствии возникновения клинча.
(18)
С другой стороны, это архитектурный баг. В системе высокая связанность должна быть в одном документе, а не в разных.
эрудированностью
Ну на тебе для понимания красоты:ACID (от англ. atomicity, consistency, isolation, durability) — набор требований к транзакционной системе, обеспечивающий наиболее надёжную и предсказуемую её работу — атомарность[⇨], согласованность[⇨], изоляцию[⇨], устойчивость[⇨]; сформулированы в конце 1970-х годов Джимом Греем[1].
Набор требований считается фактическим стандартом для высоконадёжных систем, прежде всего, реляционных СУБД, при этом с середины 2000-х годов для построения распределённых СУБД предполагается отказ от части требований ACID (для обоснования чего используются теорема CAP, теорема PACELC) или снижение строгости требований (BASE).
Под транзакционнной системой часто понимают именно СУБД, но принцип атомарности позволяет и над СУБД обеспечить согласованность данных. Например, совместное проведение зависимых документов, чтобы изменения в основном документе не привели к нарушению согласованности данных.
Набор требований считается фактическим стандартом для высоконадёжных систем, прежде всего, реляционных СУБД, при этом с середины 2000-х годов для построения распределённых СУБД предполагается отказ от части требований ACID (для обоснования чего используются теорема CAP, теорема PACELC) или снижение строгости требований (BASE).
С другой стороны, это архитектурный баг. В системе высокая связанность должна быть в одном документе, а не в разных.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот