Открыл вот более новую чем у меня УТ и смотрю, что практически у всех документов отключено автоматическое удаление движений. А удаляются движения обработкой общего модуля. Кто скажет, это вообще с какой целью сделали? Чем автоматическое удаление не угодило?

(0)Блокировка при автоматическом удалении сурьезная была - вот и отказались от неё

(1) Косяк платформы? Это как с использованием в автоматическом режиме механизма последовательностей?
Других причин нет?

(1) в общем понятно. Спасибо!

(1) интересно блокировки на какой-то конкретно СУБД возникали или на всех?
И еще интересно насколько замедлилось распроведение документа при таком подходе...

(4) ну, я думаю очевидно, что на всех. А почему должно было замедлиться распроведение? Меня другой вопрос занимает. Неужели удаление движений, прописанное в коде, чем-то отличается от того же на уровне платформы? По идее один хрен...

(5) может они просто уже смотрят в сторону управляемых блокировок?

Кому не лень, посмотрите, что там в профалере творится при ручном и автоматическом удалении движений))) а то мне тож интересно, но лень))

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

(8) интересно а откуда такая уверенность в кривизне платформы?

(9) а зачем платформа блокирует при автоматическом удалении всю таблицу регистра? а не выборочно, как в ручном режиме?

(9) если кто не заметил, в (8) стоит не уверенность, а вопрос. У тебя есть другие предположения по поводу вопроса в (5)?

(4) по идеи автоматически может быстрей, так как не скрипт, но насколько хз

(12) если бы быстрее было, то они бы не отключили во всех конфах автоматическое удаление...

(13) они отключили из-за блокировок, по другой причине

(14) т.е. вернулись к вопросу (8)...

(15) блокируется выборочно и без режима управляемых блокировок

(16) я в курсе. В клиент-серверной версии используется индексирование полей для блокировок. Но почему при автоматическом удалении движений блокировки отрабатываеют хуже?

без автоматического удаления скорее всего быстрей загружаются новые документы... чем не вариант)

(18) не врубился. Откуда загружаются? И за счет чего это происходит быстрее?

платформа не умеет на постгре автоматом блокировки по строкам, а не по таблицам, делать - для того и сделано.

(20) т.е. это заточка под постгре? На мс все нормально?

(19) При загрузке каких либо документов программно например. Загрузке остатков и т.д. В типовых доках стоит код что если документ новый - то движения не удалять. Т.е. платформа не лазиет по регистрам и не смотрит есть ли движения у документа. Это не только при загрузке, а просто при создании и проведении нового дока. Может так новые проводятся быстрее. Надо замерить

(21) для МС - чтобы наверняка

ап, тема интересная, не хотелось бы что ветка утонула, такое ощущение, что точного ответа не знает никто а жаль.
(22) Если это так - то это полная глупость со стороны платформы.

(22) поиск существующих движений - это такой микроскопический по времени запрос, что даже не смешно...

(24)(25) это только предположение) не ругайте.
Посмотрев на код Удаления движений в УПП - не совсем быстродействующий имхо... там и запросы, и обращение к метаданным документов, выгрузки-загрузки в ТЗ и т.д.

(26) + замер не делал конечно

(26) сделано не для ускорения, а для увеличения параллелизма

При проведении нового документа , блокируются вся таблица. Так что нужная вещь . иМХО.

(28) я не говорю что для ускорения сделано, я говорю что такой эффект при проведении новых документов тоже имеет место, имхо. Ради этого конечно такое делать - бред)

правильный ответ дал господин Fragster в (28)

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

(32) если тебе хочется думать, что платформа тупая, то вряд ли кто-либо сможет тебя убедить в обратном...

(33) Ну отчего же - мне как раз хотелось бы думать наоборот, но...

Все очень просто. Вот описание главной причины.
Проведение документа в конфигурации может двигать множество регистров, причем какие именно регистры будут двигаться зависит от логики данных документа (хороший пример ПКО в БП, в зависимости от вида операции он может двигать достаточно разный набор регистров), однако для платформы он может двигать все которые ему определено в метаданных, соответственно и чистить платформа будет все. Если чистить будет конфигурация, а не платформа то она будет чистить только те регистры по которым она могла сформировать движения в данном режиме документа (на примере ПКО: вид операции). Соответственно регистров блокировться будет меньше и паралелизм увеличится.
А на счет скорости непосредственной операции удаления движений, выполняется она модулем или платформой разница незначительна по сравнению со временем работы БД (сервера или файловых операций).

(35) не так

не совсем так

потому как проверка наличия движений времени пренебрежимо мало занимает

(35) Спасибо за ответ. Только не понятно почему платформа не работает по такому же принципу, почему бы ей не бегать мо метаданным а смотреть какие движения сделал документ и только эти движения чистить?!

(35) у меня нет под рукой БП. Но в тех документах, которые мне попадались, всюду вызывается просто банально процедура общего модуля, которая чистит движения ВСЕХ регистров...

(39) да блин, при автоматическом удалении движений на postgre будет блокироваться вся таблица итогов и движений по тем регистрам, по которым происходит удаление движений. а при ручном - идет ручная расстановка блокировок - и паралельно с этим другие могут по другим значениям измерений проводить/распроводить документы

(38) думаю (не проверял) что там нет ни какой проверки, т.к. с точки зрения программиста БД она не имеет ни какого смысла, т.к. проверку эту надо выполнять в той же транзакции и она должна установить ту же блокировку.

(40) это вопрос к разработчикам конкретной конфигурации на счет оптимальности их кода.

(39) см. (43) проверку делать смысла нет.

(44)+ см. (42)

(35) думаю, что ты не прав. Вот смотри. Открываем проведенный документ. Меняем там вид операции. Новые движения сформируются по новому списку регистров. Но почистить нужно все старые движения, независимо от того, какой вид операции был до этого. Я не видел, чтобы где-то в типовых кто-то скрупулезно прописывал удаление по определенным регистрам в зависимости от значений реквизитов конкретного документа...

(41) ясно, могу ошибаться но в типовых (у меня нет последних релизов) вроде как нет ручной расстановки блокировок, т.е. тупо чистятся все регистры по которым были движения.

(46) там не прописывается. Там ищутся сначала есть ли движения по регистрам... в тех в которых есть - чистятся, другие не трогаются. А как я понял платформа трогает ВСЕ регистры данного документа. а так - не все.

При отсутствии записей по регистратору в регистре, а они отсутствуют всегда у нового документа, СУБД блокирует весь регистр. И блокировка снимается только по окончании проведения, т.к. выполняется внутри транзакции проведения. Понятно что в это время никто другой не может провести свой документ. Причем блокировка будет наложена не только в момент записи, но и при попытке чтения, для проверки наличия записей в регистре.

(48) пожалуй да...

(48) в (38) сказано, что время это ничтожно мало - и в это хочется верить.

(0) Я так понимаю, при автоматическом удалении движений у тебя в начале проведения набор записывается пустой набор, далее после проведения уже заполенный -  то есть идет запись 2 раза.

При не автоматическом перезаписывается только в конце проведения.

(51) я уже не про поиск, а про блокировку регистров. если удалять по найденным - Блокируются найденные регистры, а не ВСЕ регистры, по которым документ может сделать движения

(52) даже вот так? О_о

(52) нет. В типовых прописано что при неавтоматическом - УДАЛЯТЬ движениея. Т.е. запись 2 раза также. Сначала удаляет, потом записывает

(55) + там в Обработке проведения в начале вызывается процедура удаления движений

(55) У меня под рукой только ЗУП, вроде там запись 1 раз идет.

(57) в УПП удаляет сначала

(58) Проверил в ЗУП "Начисление ЗП", так он действительно записывает одын раз.
Все грамотно.

(58) а как там с рекомендацией от 1С не записывать движения по регистрам в явном виде в обработке проведения? Чтоб они записывались автоматически про окончании обработки проведения. Вроде ж была такая рекмендация именно для устранения проблем с блокировками...

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

а может это задел на то что в дальнейшем будут анализироваться текущие движения со старыми и будут прописываться в движения только изменения?

(61) с этим вроде разобрались уже. Понятно.

В принципе 2 раза движения записывать это не кошерно.

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

(59) УПП. ПТУ по регистру Хозрасчетный - Записывает вобще несколько раз. Первый - пустые движения. Второй и последующие - проводки из модуля ПТУ, общих модулей, подписок на события.
(60) вот тебе и рекомендации.

УПП 1.2.25

(65) т.е. таким кодом они пытаются решить проблему блокировок? Херасе. О_о

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

(67) не включился про порядок записи.

(66) да нет вроде, ничего там решать не пытаются) одно узкое место при автоматическом удалении движений закрыли только. А что пишется несколько раз - к удалению движений уже отношения не имеет. Такая вот УПП.
Ещё раз повторюсь, что в УПП код по удалению движений стоит в самом начале Процедуры Обработка проведения:

   Если мУдалятьДвижения Тогда
       ОбщегоНазначения.УдалитьДвиженияРегистратора(ЭтотОбъект, Отказ, Истина, РежимПроведения);
   КонецЕсли;

т.е. Он просто затирает движения, если надо.

(68) Если разные документы (независимо от их вида) пишут регистры в разном порядке, то возрастает риск взаимоблокировки. Первый док записал 1й регистр, а 2й док - 2й регистр, потом 1й док хочет писать 2й регистр, а 2й док - 1й регистр, и всё тушите свет.
(69) УдалитьДвиженияРегистратора в УПП очищает не все регистры, он не трогает регистры отложенного проведения и партий, работа с которыми особо ресурсоёмка.

(67) не оптимальнее ли для распараллеливания работать с ТЗ, которая будет формироваться и передаваться во все процедуры общего модуля параметром, вместо запросов к предварительно записанным таблицам БД?

(70) а работа с партиями в УПП сделана всегда отложенной? Или это регулируется пользователем все-таки?

(71) УПП работает по принципу разделяй и властвуй. И не факт что таскать  ТЗ на сервер и обратно это хорошо, особенно если придётся тащить на клиента громоздкие записи по партиям.
(72) Всё настраивается, но для больших баз выбор не велик. И я писал не только про партии, но  и про проводки БУ.

(73).1 А формировать и ТЗ, и движения на сервере - это проблема?

Уже было пару ответов правильных , нет же идут опять на кофейной гуще годать .