Доброго времени суток!

Платформа 1С 8.3.12

Вопрос по типовому механизму "ИсторияДанных". В данной версии платформы он уже есть, правда несколько с урезанным функционалом. Суть проблемы в том, что новая "Версия данных" сохраняется при любой записи объекта, т.е. не важно изменился объект или нет - соответствующая запись все-равно запишется в БД. НАшел вот такую статью (не сочтите за рекламу), где в комментах этот факт подтвердили:

http://catalog.mista.ru/public/699109/

Выдержки:

"Данные истории мы храним в отдельных таблицах информационной базы. Для повышения эффективности мы храним только разницу между версиями данных. Если у вас есть «тяжёлый» документ с большим количеством строк в табличной части, а вы меняете только один реквизит в самом документе, то в истории данных сохранится только одно это изменение. То есть у вас не будет храниться множество копий этого объекта, и занимать место на диске"

...

"Создается только запись о факте записи версии. Если не было изменений - то никакие больше данные в ней не храняться. Поэтому много места даже много таких версий не съедят"

Итак, вопрос - пробовал ли кто-то сделать так, чтобы запись делалась ТОЛЬКО тогда, когда объект изменился, по отношению к предыдущей версии?!

П.С. На вопрос "для нафига все это?!" отвечаю - "для экономии места"

(0) А нормальную платформу с полноценной поддержкой истории данных не судьба поставить?

(1) Например, в какой версии платформы, можно произвести соответствующую настройку?!

?

(2) В 8.3.15 добавили обработчики, в которых можно перехватывать запись истории. Читайте ИТС.

А сколько места ты таким образом собрался сэкономить?

(4) Дай ссылку

(5) Все что сэкономлю - все МОЕ!

ап

А подписка-то на ИТС есть? :)

https://its.1c.ru/db/v8315doc#bookmark:dev:TI000001938

с этим механизмом мало кто работа я вчера в пустоту спрашивал ИсторияДанных.УдалитьВерсии - можно-ли удалить удаление?

по сабжу:

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

из явных минусов
1. очень медленный,
2. отборы не все работают
3. плохо задокументирован
4. не поднимает ошибки, вместо просто что-то может игнорировать

+
5. встроен типовой интервал 20 дней хранения истории, сделать другой интервал нельзя
6. при удалении промежуточной версии результат не пересчитывается
7. данные хранятся в очень странном формате "представление+ссылка", что с одной стороны хорошо, с другой стороны не работают типовые механизмы типа заполнитьзначения()

(10) А после удаления данные обновил?

(9) Лично у меня нет. А обязательно должна быть?

Чем платформенная история лучше бспшной?

(14) при записи обьекта работает намного быстрее

и можно ли её отключить, если уже версионирование ведется в базе? она же явно влияет на скрость.

(16) Можно

(16) Ведение истории по умолчанию включено для реквизитов, но отключено для объекта. Я сделал обработку по включению объекта метаданных в ведение истории и новый объект, который нужно версионировать одной галочкой включается. Для механизма из БСП нужно в нескольких местах код в конфигураторе прописать.

(10) и (11) Почитайте внимательнее по ссылке с ИТС (это же и ответ на ваш п.3). "20 дней" - это про стэк постобработки написано, удаление самих версий регулирует разработчик. Т.е. нужно написать некий аналог функционалу БСП, по регламентной очистке старых версий.

бсп до сих пор его не юзает. почему? вот вопрос

Еще момент - механизм БСП ограничен по 3 типам объектов, а в платформенном еще и РС можно версионировать.
http://catalog.mista.ru/public/1151547/

А отчет по сравнению нужно самому писать?

(22) Это сразу же появляется в списках "платформенно".

(23) Озвученную проблему в (0) можно решить?

(16) Её можно не включать :)

(24) Читайте официальную документацию.

при записи явно меняется версия данных-служебное поле,видимо,в историю и оно тоже пишется.
опять же,если они хранят и представления для ссылок,то очень сложно отслеживать изменения.

с другой стороны,заготовил историю,конвертнул в строку,посчитал md5 или sha и сравнил с прошлым разом-это же не сложно.

(26) ТЫ как попугай. Читал я официальную документацию. Если бы там были ответы на ми вопросы, ТО ДАННАЯ ТЕМА БЫ НЕ СОЗДАВАЛАСЬ.

(27) как сравнить это уже другой вопрос, он уже решен в БСП...как раз по принципу сравнения хеша.

Вопрос в возможности отловить событие записи версии и при необходимости его отменить.

изменение истории данных - отдельный бизнес-процесс. хранение таких данных в oltp базах данных не допустим.

(28) Вот ты ленивый. Цитата "Реализована возможность отменять запись истории данных. Реализовано свойство ПараметрыЗаписиИсторииДанных.Отказ"

(30) а где ее по вашему хранить нужно,особенно с учетом прав на доступ к данным ?

(32) В текстовых файлах, вестимо :))

(32) в "отдельно стоящей" базе. недопустимость обоснована разными требованиями к резервному копированию.