Версионность объектов 1с #704263

Доброе время суток ребята. Я решила сделать версионность объектов в 1с, хотела бы у вас спросить совета как это лучше сделать. В данный момент мне нужны только документы. Я примерно представляю это так: 1) регистр сведений в котором мы будем хранить изменения. С ресурсом пользователь, объект, вид методанных (реквизит или табличная часть), тим записи (добавление, изменение) . Регистр периодический в пределах записи. Так же два ресурса как было и как стало.   2) Все изменения заносить подпиской на событие перед записью. Заносить в регистр только измененные реквизиты. 3) И отчет по этому регистру какие изменения были. Я понимаю что регистр вырастит до невероятных объемов. Документов в системе много. Средний пул документов в день примерно 1000-2000 документов. Я думаю что это довольно нужная и интересная тема для обсуждения. Жду ваших комментариев. P.S. Хотелось бы услышать от вас как упростить данную схему и сократить регистр.

Тема совершенно не интересна. Всё давно решено и раскрыто. Начиная с типовых (где есть версионирование) до статей на нимфосрате, в которых раскрывается вся сущность.

Открой для себя БСП

Что то я не нашла не одной статьи, может я не правильно поиском пользуюсь?

Судя по всему - неправильно.

Ну а если изменений много - то версионирование будет ресурсоемким. Обидно, но неизбежно.

Если не трудно, скиньте пожалуйста ссылку.

Еще небольшая пометка, 1с стоит на платформе 8.1.

? Хранение и просмотр истории изменений справочников и документов (пользователь, внесший изменения, время изменения и характер изменения с точностью до реквизитов объекта и реквизитов его табличных частей). ? Сравнение произвольных версий объектов. ? Просмотр и откат к ранее сохраненной версии объекта.

Это описание подсистемы версионирования из БСП.

В УПП сделано очень хорошо

Хм... БСП - для 8.2 Будет повод перейти.

Хотя, если переходить - то можно уже и на 8.3

Перейти вряд ли получится. у нас полностью самописная конфигшурация. И она написана полностью на связях с внешними данными. Боюсь плохо будет при переходе.

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

А ты не бойся и попробуй. Страшных сложностей не предвижу.

Это да. Хранение представлений - это гуд.

Эврика! как я и забыла что можно писать xml в хранилище значений. Мне не нужно откатываться на старые версии. достаточно лишь следить за пользователями.

получается что в хмл я могу записать реквизит ссылки и Значения ссылки а так же реквзит объекта и значение объекта.

+ Но в рабочей базе - еще более ресурсоемко. Да и вообще я к версионированию в чистом виде отношусь с прохладцей. Очень редко оно нужно. Чаще нужно просто знать, кто чего где когда поменял. И не всегда с максимальной детализацией. А для этого достаточно продуманных записей в ЖР.

типовой БСП и пишет хмл в регистр, тут все дело в формате этого самого хмл...

у меня задача прикольная, я сделал что все материальные документы подписываются МОЛ и после подписи никто ничего не может поменять. Народ взвыл, теперь приходится делать механизм при котором менять можно, но через подписи :)

Я не разу не сталкивалась с БСП. Сейчас читаю документацию. А что сложного в этом формате? Просто получается у меня есть документ и реквизиты, в хмл записывать только измененные реквизиты. Получается что он будет очень простого типа. Примерно так: Реквизит1    Значение1 Реквизит2    Значение2 Табчасть    Реквизит1       Значение1 Ну и так далее.

Ну, тут без вариантов. Если есть подписи, то нужно и версионирование с переподписыванием.

Нашла в бух 3.0 версионность, сейчас гляну как там реализованно.

Во-первых, нагруженные системы не любят запись в ЖР кучи событий. Во-вторых, коврыять текстовые файлы на предмет "кто чего где когда" то ещё удовольствие, у нас в сезон этот ЖР по гигу в день добавляет.

Я тебя умоляю. Каких кучи событий? Сначала повключают на максимальную детализацию, когда каждое движение в ЖР пишется, а потом жалуются - ЖР мол, отстой.

я скачал готовую подсистему "версинирование объектов" и не знаю горя теперь. Любой объект можно версинировать, а можно не версинировать. Регистр можешь чистить без проблем. Легко ставится. Это проще, чем самой писать.

не тратьте время. Ставьте готовую. И под себя её допишите.

Нагруженные системы всегда куча событий, а тут предлагается ещё к ним что-то дополнительно в журнал писать. А как писать в журнал не каждое движение, а через одно, я может отстал от жизни, но  - либо пишем всё, либо пишем ошибки и предупреждения?

Я веду речь об "ошибки и предупреждения", а все остальное, чего надо - самому писать.

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

Плюс готовые средства анализа, как встроенные в платформу, так и в БСП. Если не вываливать в ЖР всякий ненужный шлак типа движений регистров, то всё довольно шустренько анализируется.