В данный момент уже очень многие конфигурация содержат БСП (библиотеку стандартных подсистем), в составе которой есть подсистема «Версионирование объектов». Эту подсистему можно использовать как в в режиме «Управляемого приложения», так и в принципе и в режиме «Обычного приложения» без появления автоматической команды для просмотра истории в форме объекта.
Что делает эта подсистема? Подсистема предназначена для хранения версий объектов (справочников, объектов), которые может многократно менять пользователь или обработки. В дальнейшем всегда можно посмотреть все версии, которые были изменены и сравнить их между собой. В результате вопрос кто виноват и когда это было сделан решен, это классно!!!
Включается эта подсистема в интерфейсу управляемого приложения в пункте «Администрирование-настройка системы — Использовать версионирование объектов». Далее настраивается виды объектов, т.к. какие документы и справочники, по которым будет идти версионирование.
Кстати говоря, о вариантах версионирования, то вариант «Версионировать при проведении» означает, что сохраняется версия документа после первого проведения, а затем уже всё время, чтобы с документом не делали версия сохраняется при записи. Поэтому правильнее было бы его назвать «Начать версионировать после первого проведения документа».
Но как уже упоминалось выше проблема в том, подсистема слишком напрягает базу, а именно возникают проблемы:
- Тратится время на сохранение версии объекта. Это влияет на то, что например перепроведение документов заметно замедляется .
- Заметно увеличивается размер базы данных, что требует беспокоится о свободном месте, где находится база данных. Да и раздражает немного, что выгрузка базы (dt) занимает гораздо больше времени.
Проанализируем эти проблемы и попробуем найти пути оптимизации.
1. Тратится время на сохранение версии объекта
- Механизм сохранения построен на подписке события для СправочникОбъект и ДокументОбъект событи ПриЗаписи. Последовательность такова:
- определяется нужно ли этот объект версионировать , определяется это из настроек в регистре сведений НастройкиВерсионированияОбъектов
- версия объект сериализуется в XML, помещается в ХранилищеЗначений и записывается в регистр сведений ВерсииОбъектов, при этом каждой версии присвается следующий порядковый номер в записи в реквизте НомерВерсии
Основное время уходит как на сериализацию объект (преобразования в XML) и собственно на запись этого серилизованной версии в регистр.
2. Заметно увеличивается размер базы данных
Размер увеличивается за счет количество сохраненных версий в регистре. Ведь каждая версия это по сути копия объекта и получается копий будет столько, сколько раз записывали документ (т.е. редактировали, проводили и отменяли проведения, помечали на удаление и т.п.). Так на один документ может приходиться и 10 версий и тогда у вас реально документов в базе «как бы» в 10 раз больше.
Решение этих проблем это смена подхода как к сохранению изменений, так и и количества сохраненных изменений. Есть много уже готовых решений, которые отлично работают(их много и на Infostart). Подходы у эти разработок сводится к тому, чтобы проанализировать , что именно изменилось и сохранить только изменения. А затем , когда есть текущая версия, то через динамику изменений можно восстановиться до любой версии. Некоторые решения ещё предлагают сохранять все эти изменения в другой специальной базе или время от время переносить накопленные изменения в другю специальную базу. Эти решения отлично работают, но ими нужно специально заниматься. Приобретать, устанавливать, настраивать. Но если требуется действительно серьезный и даже критический подход к хранению изменениям, то на это стоит потратить и время и деньги.
Но мы стараемся оптимизировать работы именно механизма работающего в БСП. Идея оптимизации будет состоять в том, чтобы уменьшить количество версий объектов, если реально эти объекты не меняются. Не будем сохранять версии объектов , если они не меняются, но будет фиксировать факт записи объекта в базу. Последнее нужно будет, например, чтобы знать документ перепроводили или нет.
Итак делаем
1.) Чтобы можно анализировать измененность объектов события ПриЗаписи не подходит, т.к. в этот момент уже предыдущая версия перезаписана. Поэтому будем использовать событие ПередЗаписью. Создадим две подписки на событие ПередЗаписью отдельно для справочника и документа для того, чтобы дополнительно зафиксировать информацию о режиме записи документа (проведение, отмена проведения, запись). Также дополнительно сохранять будет информацию о пометке удаления объекта, это позволит визуально быстро понимать, что с объектом ничего не делали, а просто пометили на удаление. Сами процедуры обработчики события поместим в общий модуль ВерсионированияСобытия. Таким образом, в обработчике события ПередЗаписью, когда объект ещё не записан в базу, текущая версия будет находится в Источнике (справочникОбъект или документОбъект), а предыдущая версия в Источник.Ссылка.
2.) Проверив, что объект версионируется, начинаем анализировать , а изменился ли объект? Как ? Тут я решли поступить просто раз объект сериализуется в XML,а XML это строка, а строки можно сравнивать. Берем XML текущего объекта и XML версии в базе данных и сравниваем, если ещё точнее сравнивать будет строки XML помещенные в ХранилищеДанных сжатые. Выглядет примерно это так:
3.) Если версию отличаются, то значит её нужно просто всю записать (не разницу чем отличается). Если не отличается, то саму версию сохранять не будет, однако запись о том, что объект записывался (проводился и т.п.) добавим в регистр сведений. При этом сделаем на ссылку на номер записи, от которой данная версия не отличается.
4.) Есть ещё один момент. Не будем сохранять текущую версия объекта сразу при записи, а только если появляется новая действительно измененная версия. А зачем сохранять текущую версию сразу, если она и так в базе сидит в виде документа. Это позволит, если документ один раз ввели и потом практически не меняли, то количество версий сохраненных будет минимально.
5.) Таким образом в регистре сведений ВерсииОбъектов будут записи , в которых действительно хранятся версии объекта (базовые версии), а остальные записи ссылаются только на базовые версии, т.к. при записи объектов они не менялись.
6.) Так как на сравнение версий все равно уходит время, нужно предусмотреть, чтобы в ситациях когда это не нужно делать, можно было обойтись без этой проверки. Например, делаем перепроведение документов , сами документы при этом не меняются, зачем что-то сравнивать. Поэтому добавим в ДополнительныеСвойства объекта флаг ПроверятьНаИзменениеСПредыдущимиВерсиями. Но чтобы этого флаг добавить придётся делать собственную обработку по групповому перепроведению документов, я их обычно делаю или беру где-нибудь для работы в программах, пользователи пользуются только этим перепроведением.
7.) Чтобы теперь сравнивать версии нужно учитывать, что в каждой записи сохраненной версии может и не быть, а также то, что текущие базовые версии не содержат в себе данные о версии ,т.к. эта версия сейчас и есть объект в базе . Поэтому нужно эти нюансы учесть в отчете о сравнении версий ОтчетПоИзменениямВерсийОбъектов
8.) Для анализа сколько и чего уже хранится в регистре сведений ВерсииОбъектов сделан новый отчет СтастикаПоХраненимымВерсиямОбъектов, в котором можно посмотреть данные о количестве объектов, версиях , базовых версиях, размерах храненимых версиях в мегабайтах (да это тоже сохраняется при записи версии в регистр)
В итоге изменений не так уж и много нужно внести 2-3 процедуры в общий модуль Версионирования, в модуль объекта отчета о сравнении, в регистр сведений добавить новые реквизиты. Результат будет существенное экономия места в базе и скорость перепроведения (своей обработкой) возрастет.
Все что получилось выкладываю в своей базе небольшой демо базе с одним документом и справочником, там же есть простая своя обработка перепроведения документов. Всё это можно использовать как доработку БСП , так и как отдельное решение сравнив и объединив. При встраивании в свои конфигурации нужно понмнить о том, что список объектов нужно задать в общей команде ИсторияИзменений в типе параметров команды, а также тип измерения Объект в регистре сведений ВерсииОбъектов, основная измененная процедура — это ВерсионированиеОбъект. ЗаписатьВерсиюОбъекта. В качестве основы бралась старая версия БСП 1.1.2.3, но текущая версия по этой подсистеме принципиально не отличается.
Related Posts
Восстановление последовательности документов при закрытии месяца в Бухгалтерия 3.0 не завершается
Заполнение табличных частей
Формирование сводных актов выполненных работ
Ввод поступления в переработку на основании передачи сырья (между организациями)- Конспект по установке сервера 1С на linux
Получение имени компьютера и его IP локально и в терминале
Мне кажется, что это какое-то вредительство.
Что происходит в БСП:
1. Проверка настроек версионирования
2. Считывание номера последней версии из базы
3. Сериализация объекта
4. Запись в регистр
Что я увидел у Вас:
Представим, что пользователь просто нажал ОК ничего не изменяя.
Первые 2 пункта не отличаются
1. Проверка настроек версионирования
2. Считывание номера последней версии из базы
дальше самое интересное
3. Получение пометки на удаление по ссылке через точку: Источник.Ссылка.ПометкаУдаления
4. Сериализация объекта
5. Считывание из регистра предыдущей версии элемента справочника
6. Какая-то проверка и еще раз считывание уже какой-то другой (исходной) версии этого элемента
7. Сериализация объекта полученного по ссылке. Т.е. полное чтение объекта из базы. Ссылка.ПолучитьОбъект()
8. Запись в регистр без сериализованной версии объекта.
Хорошая такая оптимизация получилась. Вместо 1 раза сериализация выполняется 2 раза. Плюс к этому еще 4 раза зачем-то обращаемся к базе. И все равно выполняем запись в регистр. Тут уже не сильно важно есть там сериализованый объект или нет (если только он не очень большой). В каких-то отдельных случаях может произойти ситуация, что придется выполнить еще одно чтение из регистра и еще одну запись в этот регистр.
И ради чего это? Ради экономии пары гигов дискового пространства? Вам жалко что ли?
Может проще в часы простоя регламентным заданием чистить этот регистр от старых записей?
(1)
Согласен, что функционал по определению, пометили ли на удаление объект, нужно сделать опциональным. Мне он был нужен, подумаю.
Разница есть при записи документом с большой ТЧ, быстрее сравнить версии, чем записать эту большую версию в регистр. Запись практически пустой записи отличается по времени от записи с ХранилищеЗначения большого размера (несколько килобайт)
Может проще в часы простоя регламентным заданием чистить этот регистр от старых записей?
Действительно жалко место, только на 2 гига, а гигов 20 и администраторы серверов начинают беспокоится о месте на сервере (500 Гб), особенно если надо развернуть копию и что-то проверить.
А обработка, которая удаляет лишние версии, у меня есть. Эта обработка переводит хранение из структуры хранения версий в БСП в мою структуру, удаляя лишние (одинаковые) версии.
Ну и главное, перепроведение. У меня на база перепроведение ДО занимало часов 8, ПОСЛЕ 1 час, т.к в этом случае не происходит ни сравнения версий , ни записи этих версий, а только информация о том, что документ проводился.
Если очень надо, то лучше пометку получать запросом, а не через точку по ссылке. Тем более, если у Вас документы с большим количеством записей в ТЧ. Сейчас чтоб получить пометку, тянется вообще весь объект.
Для больших объектов актуально. Согласен. Но для маленьких это того не стоит. Проще его записать, чем выполнить кучу накладных манипуляций.
Если у Вас MS SQL, то как вариант можно этот тяжелый регистр хранить в отдельной файловой группе и не бекапить ее. Только скорее всего при каждой реструктуризации придется заново переносить таблицу. Возможно на инфостарте кто-то этим уже заморачивался, надо поискать.
Здесь полностью согласен. Чтоб облегчить групповое перепроведение, надо костыль прикручивать. Либо на этот период вообще отключать версионирование этих документов.
В общем что хочу сказать. Я так понимаю, что выигрыш достигается только на тяжелых объектах и только когда текущая версия объекта не отличается от предыдущей. Но для этого я бы сначала собрал статистику. А то у меня есть сомнения на этот счет. Для начала надо посчитать, при каком весе объекта его запись становится дороже расходов на сравнение и пр. Потом оценить вес имеющихся версий. Если есть такие объекты и их много, то надо бы собрать статистику, часто ли происходит перезапись неизмененного объекта. Если из 10 версий 1 неизмененная по отношению к предыдущей, то наверное не стоит заморачиваться. В любом случае надо замеры делать.
Ну и спасибо за попытку сделать что-то полезное.
ИМХО.
Серилизация сама по себе занимает крайне мало времени, а вот сравнение — да. При записи документа нужно делать минимум телодвижений, ИМХО в БСП как раз все правильно — получили номер версии, сериализовали и записали, а анализ весь потом. Если уж так заботит размер базы — создайте регламентное задание, которое будет версии шерстить и удалять лишние или удалять больше определенного числа версий на объект. Я бы даже не искал последний номер версии, а писал GUID, потом можно отсортировать по дате записи версии (только не помню, если ли дата записи в стандартной БСП).
В идеале, посмотреть бы нагрузку на проц сервера приложений и на диск на SQL базе в момент перепроведения документов.
(4)
Это не аксиома, всё зависит от ситуации. Большинство решений по накоплению изменений объектов делают анализ именно перед записью.
Послушайте, но какая разница делать это сразу или регламентным заданием с точки зрения времени, все равно суммарное время будет одинакова при любом способе. Тут опять же зависит от условие эксплуатации конкретной базы. Если сидят до 10 операторов работают в файловых обычно базах, и к ним иногда забегает администратор(-программист), то наверное лучше всё сразу делать при записи. Если это админ в компании, который действительно всем занимается, может контролировать запуски регламентных заданий , результат этих запусков, то наверное тогда лучше делать регламентным заданием.
Поэтому опять же вижу, что это можно сделать настройкой типа «Сравнивать версии при записи» или «Сравнивать и удалять одинаковые версии регламентным заданием».
(3)
Да запросов можно это сделать. Но тут у меня пока так получается, что сначала я получаю пометку удаления, а потом все равно для сравнения делаю ПолучитьОбъект, по идее когда я считываю пометку уже ПолучитьОбъект считает из кэша, т.е. не будет двойного чтения из базы. Но повторюсь, что , считаю что для пометки лучше сделать запросом.
Со статистике я и начал думать обо всем этом.
(0) ну ведь глаза сломаешь, пока дочитаешь твою статью. В ворде хотя бы проверил, что ли…
Мысли вижу правильные, но реализация — пока что костыльная. Конечно, хранить полную сериализацию объекта в каждой записи, тем более не измененной, это жирно будет. Но 4 раза читать из базы, 2 раза сериализовывать — перебор, ИМХО. Тут скорее как Silenser в (4) написал нужно подчищать регистр периодически.
И еще вопрос: в том случае, когда для группового перепроведения используется не специализированная обработка, а динамический список, например, что прикажете? Отказаться от типового удобного механизма, за которым никуда лезть не нужно, в пользу отдельной обработки?
(7)Но 4 раза читать из базы, 2 раза сериализовывать
С чего это решили, происходит все лишь дополнительное чтение объекта сохраненного в базе 1 раз.
2 раза сериализовать — 1 раз и так сериализуется в стандартном БСП , а 2-ой раз нужно для сравнения. Что не так?
(5) Попробую навести вас на мысль: допустим регламентное задание потратило суммарно 30 мин на анализ и удаление лишних версий (при этом 28 мин ушло на анализ, а 2 мин на запись, при этом продолжительность каждой отдельной транзакции была минимальна, т.к. анализ выполнялся вне ее), а суммарно анализ внутри процедуры ПередЗаписью потратил 20 мин (при этом и анализ и запись вся суммарно заняла 20 мин, т.к. все выполняется внутри транзакции записи документа).
(9)Ничего не понял, сформулируйте по-другому, что хотите сказать
(10) Увеличение числа телодвижений внутри транзакции ведет к увеличению ее продолжительности. Увеличение продолжительности транзакции ведет к увеличению числа одновременно активных транзакций. Увеличение числа одновременно активных транзакций ведет к риску эскалации транзакций, таймауту или деадлоку.
(11) Да, теперь понял. Конечно время транзакции увеличится, тогда вариант с регламентным заданием может быть будет и лучше. Но думаю все равно надо анализировать ситуации каждый документ и его поведение в каждой базе, как эксплуатируется база. Например, Справочник «Организации» редко редактирует, я думаю можно и при записи всё сделать, а расходный документ уже может быть и блокировки. Просто не нужно забывать о «бедных» бухгалтерах, кладовщиках, которые работают одни в базах и нет у них помощи со стороны администраторов, я думаю там само всё должно работать.
Итог, думаю в идеале сделать нужно, чтобы версионирование гибко настраивалось по каждому объекту, настройки типа:
— сразу проводить сравнение или регламентным заданием
— регистрировать ли информацию о записи объекта, если версия не изменилась
— нужно ли регистрировать данные о пометки удаления, режиме проведения.
(12) Опять же ИМХО, если у бухгалтеров или кладовщиков нет помощи от админов или разработчиков, то организация скорее всего маленькая и документооборот небольшой. Так что можно даже немного вольностей себе позволить при разработке, все равно они особо разницы не почувствуют, пока их в базе одновременно человек 30-50 не окажется.
(8) я хотел сказать, что производить достаточно громоздкие проверки при каждой мало-мальской записи — не есть гуд. Вижу, что понимание этого тут уже родилось.
Однако, могу и в пользу Вашего решения высказаться (и не буду стесняться в этом!): Ваш вариант вполне пригоден к применению, если использование регламентов по тем или иным причинам невозможно или затруднено. Причинами могут быть небольшая контора без толкового администратора базы, использование файлового варианта (опять же малопригодно для большой конторы), или еще что-то. С удовольствием продолжу конструктивный диалог, послушаю какие еще причины могут способствовать применению Вашего варианта.
Тем не менее, хочется услышать что-нибудь и про групповое перепроведение без использования специальных обработок. А такое вполне возможно на базах любого размера, любого документооборота, любого количества пользователей.
(13) Silenser, если их окажется «человек 30-50», то это уже не маленькая контора. Да и в файловом варианте работать такой оравой негуманно. Опять приходим к регламентному заданию.
(14)
Тут вы сразу крест поставили на кучу решений (,
и прочее и прочее)
Как я знаю перед записью документа в момент перепроведения нельзя понять, менялся ли документ или нет, чтобы ничего не сравнивать объект с текущей версией в базе. В момент перепроведения он считается измененным, поэтому передать признак, что не нужно делать дополнительные действия нельзя.
Честно говоря мне эта тема не так интересно. Потому что в любой мало-мальски хорошей конфигурация, логика оптимального проведения не подразумевает, что нужно всё перепроводить и все движения переделывать, поэтому появляется в конфигурации свои обработки перепроведения (возьмите Бухгалтерию хотя бы), свои кнопки перепровести у пользователя, последовательности (по партиям_ и т.п.)
(15)
Можно предположить, что если функция Модифицированность() дает истину в процедуре ПередЗаписью, то объект скорее всего изменен. Тогда можно в допсвойства закинуть некий признак и в ПриЗаписи выполнить некие действия по записи версии. Для документа еще нужно будет сравнить флаг проведения, если не ошибаюсь, его изменение на модифицированность не влияет.
(16)
Надо это проверить. Вроде раньше влиял.
(15) я не сказал, что категорически нельзя проводить проверки перед записью. Я лишь поставил под сомнение правильность и оптимальность проверок. Это как раз то, о чем уже говорил Silenser: стОит ли овчинка выделки?
Еще раз обрисую ситуацию: любая типовая на управляемых формах, форма списка — скорее всего является «Динамическим списком», можно выделить несколько документов (в том числе все) (а предварительно настроить отбор и сортировку) и нажать «провести». Специальная обработка — не требуется, перепроведение — групповое, конфигурация — типовая, «хорошая?» — «не плохая». А если говорить о перепроведении вообще, то в «хорошей» конфигурации его быть не должно, ИМХО. Нужно изначально не дать пользователю сделать неправильно.
(18)
Проверил Модифицированность() даёт Истину, если перепроводишь документ.
Поэтому, я не знаю пока стандартного решения, как отличить «простое перепроведение» от «изменения проведенного документа (как программно, так и интерактивно) и его последующем проведением»
Есть встречное предложение: называть это не «оптимизация», а «надстройка» над подсистемой версионирования объектов. То есть не заменять типовой механизм, а дополнять его. Опционально.
Может быть смазано высказываю свою мысль: система выборочного хранения записей в регистре — это хорошо, а вот как складывать записи в регистр или чистить его («оперативно» или «регламентно») — сделать настраиваемым. И, например, при первом запуске, или периодически при запуске, проверить число пользователей в базе (при большом количестве рекомендовать регламент). Или проверить режим базы (для файлового варианта рекомендовать (жестко так рекомендовать) оперативный механизм). «Пусть лошадь думает — у нее голова большая». Пусть база сама определяет большая она или нет…
(19) еще раз повторю вопрос из (7): как поведет себя Ваша подсистема при использовании группового перепроведения из динамического списка?
По логике вещей запись о том, что документ перепровели должна остаться, а вот сериализация объекта в регистре сохраняться не должна. Правильно? Как дело обстоит на самом деле? Нужно ли мне подтягивать отдельную обработку, чтобы перепровести несколько документов? (при том, что в динамическом списке выбрать какие именно нужно перепровести — реально дело нескольких секунд).
Конечно, если перепроводятся документы разных типов, восстанавливаются последовательности, используется хитрый алгоритм и прочее — тут не отвертишься от специализированной перепроводилки.
(21)
Да всё правильно.
Просто я понял мы обсуждали, как при перепроведении динамических списков избавиться от сравнения версий и пока решения нет. Сравнение производиться будет, но одинаковые версии в регистр записывать не будут, будут только записи о проведении (пустышки), которые ссылаются на записи базовых версий.
На мой взгляд оптимизация должна подразумевать вынос наиболее затратных действий в регламентную обработку. Например так:
1. ПриЗаписи в отдельный регистр фиксируется признак ВозможноНадоСохранитьВерсию = Истина и ссылка на объект, а также автор и дата записи (для нового объекта этот пункт не нужен);
2. Потом регламентное задание по этому регистру перебирает объекты и сравнивает их с хранящимися версиями — при нахождении различий сохраняет новую версию и удаляет обработанную строку из регистра (удаляет в любом случае)
3. На случай повторной записи объекта до регламентной обработки ПередЗаписью объекта происходит проверка на наличие флага ВозможноНадоСохранитьВерсию, и при его наличии сохраняет версию объекта ИЗ ССЫЛКИ
(23) В целом, как уже обсуждали выше, согласен, что операцию сравнения и удаления можно вынести в регламентную обработку. Но я выступаю за то, чтобы работали оба варианта: сразу при записи документа или отложено регламентной обработкой(тут как раз придётся добавлять новое поле в записи «ВерсияПрошлаПроверкаНаИдентичностьСПредыдущими»)
Есть еще более оптимальное решение. в 8.3 средствами платформы можно получать хеши. В хеш данных подаются двоичные данные от ЗаписьFastInfoset, получается хеш. В самом регистре версий добавляется ресурс с хешом версии. При записи из регистра считывается последняя версия и ее хэш и сравнивается с новых хешом. Такая доработка позволяет уменьшить объемы чтения данных из базы.
(25)
Дайте ссылку почитать про хэши. Тут главное учесть, что проводят и меняют документы разные пользователи, в разные дни.
(24) мой вариант помимо сокращения объема хранимых версий (как и в статье) хорош тем, что:
— при записи неизмененного объекта не будет никаких затрат на проверку версий, если не считать быстрого запроса флага ВозможноНадоСохранитьВерсию
— при записи измененного объекта в случае отсутствия флага ВозможноНадоСохранитьВерсию тоже не будет затрат на сравнение версий
— и только при повторной записи объекта будет 1 раз вызвана процедура сравнения и записи версии
(26) в справке конфигуратора 8.3 ХешированиеДанных метод добавить, туда подается результат работы ЗаписьFastInfoset.Записать()
итого
ДвоичныеДанные = ЗаписьFastInfoset.Закрыть()
ХешированиеДанных = Новый ХешированиеДанных(ХешФункция.SHA256);
ХешированиеДанных.Добавить(ДвоичныеДанные);
ХешВерсии = ХешированиеДанных.ХешСумма
второй вариант подавать на хеширование не Двоичные данные и строку (если работа версионирования идет через ЗаписьXML).
(27)Не пойму что вы принципиально нового придумали.
В моем варианте для новых объектов никаких сравнений и записи версий нет.
При повторное записи идет сравнение и запись версии предыдущей, если есть отличия. Исключение:проводка документов со флагом в не проверять и не записывать версию.
Также напомню, что разработка родилась,когда документы проводились за месяц около 8 часов,после запуска моей настройки 1час, т.е. Большая часть времени уходило на сериализацию версий и запись этих версий в регистр
(29) Да, я не очень понятно выразился (хотя ничего принципиально нового я не придумал, конечно):
1. Запись нового объекта- нет затрат на контроль и запись версий (как и у вас)
2. При перезаписи объекта, после регламентной обработки «ОтложеннаяЗаписьВерсий» — нет затрат на контроль и запись версий (у вас есть)
3. При перезаписи объекта, необработанного регламентной обработкой «ОтложеннаяЗаписьВерсий» — есть сравнение и запись новой версии (из ссылки до изменения!), если найдены отличия (у вас тоже есть)
4. Нет необходимости в заполнении ДополнительныхСвойств объекта
То есть, судя по пунктам 2 и 4 можно получить плюсы из статьи, не заплатив (почти) за них минусами — лишним контролем при записи и замедленной скоростью типовой групповой перезаписи объектов из журнала
(29)
мы об этом узнали только в (2), причем в конце немаленького комментария, зато с припиской «и главное — перепроведение». А из (0) мы то подумали, что вопрос о том, что «тратится лишнее время при записи» и «пухнет база». Вероятно, следовало начать с того, что оказалось «главным». По крайней мере акцентировать на этом внимание в (0). И акцентировать внимание на том, что обработка перепроведения тоже должна быть «оптимизированная», то есть заточенная под использование Вашей схемы версионирования.
Вероятно, если бы с (0) не осталось сомнений, что основной выигрыш именно на групповом перепроведении, то и вопросов и споров было бы меньше.
В свете того, что все затевалось ради перепроведения — предложение такое: комбинировать оба метода — ускоренный режим именно при перепроведении (специальной обработкой), и обычный режим + регламентная подчистка регистра при «плановом» проведении документа/записи объекта.
(28) Dpotapov, а с 8.3 тоже нужно осторожно — далеко не все перешли на новую платформу. Бывают и те, кто еще какой-нибудь 8.2.13 пользуются.
Согласен, что наверное нужно было начать описание с того, из-за чего всё начиналось, а не сразу описывать БСП.
(32) ShantinTD, В 8.2 делаю тоже самое через регламентное задание, ночью система ищет версии без хеша, добавляет его, удаляет одинаковые версии. Скорость записи измененного документа не меняется, но хоть места становится меньше.
(34) Dpotapov, я сказал о том, что «использовать хеш» на 8.3 можно, но нужно иметь ввиду, что на 8.2 встроенного хеша нет — нужно приколхозивать его. У меня, например, была самописная процедура MD5(СтрокаДляХеширования). Естесственно, поменять во всех местах ее вызов на вызов встроенного объекта хеширование — хлопотно, и неправильно. В саму процедуру внесены изменения: если версия 8.3 или выше — то встроенный объект, иначе самописный алгоритм.
А «отсталые» пользователи, к сожалению, бывают: умер комп, поставили заново 1С с диска. Только вот диск 2010 года (или 2011 — не позднее), там тебе и счет-фактура «неправильная», и платформа старая, и прочее и прочее.
(25)
А можете тыкнуть меня на материалы по хешированию, незнакомая для меня тема.
Поэтому пока не понимаю, что именно оптимальнее получается: размер версии или скорость сравнения?
(36)
(37)Правильно я понял, что вы утверждаете, что хеширование использовать оптимальнее, т.к.:
— сжатый ЗаписьFastInfoset в ХешФункцию занимает меньше в размере, чем сжатие просто типа ХранилищеЗначения?
— сравнивать ХешФункции будет быстрее чем сериализованные ХранилищеЗначения с ЗаписьFastInfoset внутри?
(38) нет. Смысл в том, чтобы сравнивать хэш версий, а не тащить из базы хранилище предыдущей версии.
(39)
Смысла не понял (сравнивать потому что можно сравнивать хеш версии а не версии объектов так?).
(40) сравниваются хэш версий объектов, так как при вытягинваии из базы будет меньше тянуться данных.
(41)
Не понял за счет чего меньше.
Что мешает серриализованные объекты сохранять в файл, и по периодам архивировать данные. Их можно складывать в дальний угол. И в случае форсмажора восстанавливать всю цепочку событий.
Да ничего не мешает мне лично и думаю 1с, главное если есть желание.
Минусы только чтобы проанализировать изменения в данных на копии базы данных нужно дудеть тащить весь архив.