Имя: Пароль:
1C
1С v8
Версионирование в БСП не использует механизмы платформы. Почему?
0 Климов Сергей
 
09.07.26
11:54
Тема на пофлудить.
Механизмы версионирования появились в платформе аж в 8.3.11. Но до сих пор в БСП не используются, всё сделано на РС. Хотя анонс был https://wonderland.v8.1c.ru/blog/istoriya-dannykh/ Но так и не был реализован.
Как думаете, почему?
1 Garykom
 
гуру
09.07.26
11:57
"Потому что гладиолус"©
1. Исторически сложилось
2. Кто будет переписывать?
3. И за чей счет?
4. "Можно а зачем?"©
5. Гибкость и управляемость потеряется же
2 toypaul
 
гуру
09.07.26
11:57
(0) Разработчики ленивые. Надо же поддерживать старые базы. А если старые базы переводить на новый механизм это думать надо много. Слишком много работы.
3 toypaul
 
гуру
09.07.26
11:58
Но кстати могли бы опцией сделать механизм платформы. По типу как производительный РЛС.
4 maxab72
 
09.07.26
12:03
либо они что-то знают про платформенный механизм, что не озвучено широкой публике...
5 ДенисСмирнов
 
09.07.26
12:22
Стандартное версионирование же сохраняет все данные (так ведь?), даже если поменял один реквизит. Неоптимально. Возможно, с этим связано, не знаю как там на этих ваших БСП
6 Климов Сергей
 
09.07.26
12:22
(4) Вот-вот. Это жжжж - неспроста! :-)
7 Климов Сергей
 
09.07.26
12:27
Вот, статью интересную нашёл: https://infostart.ru/1c/articles/1803149/
8 timurhv
 
09.07.26
12:51
(5) только если что-то менялось, если тоже самое записывается, то - нет. По хешу будут использоваться предыдущие записи, при очистке устаревших данных - перенесутся в нужную.
9 ДенисСмирнов
 
09.07.26
13:32
(8) Это в БСП так?

Просто платформа в этом смысле ведет себя странно. Даже если открыть документ, нажать записать ничего не меняя, то это приведет к реальному обновлению записи в SQL, причем всех полей. Будет выполнено update все_поля где ссылка, ну и к увеличению версии. а если включено версионирование, то и к записи ВСЕХ реквизитов, если я правильно помню.

Меня в свое время это поведение удивило
10 Dmitrii
 
гуру
09.07.26
13:55
(0) >> до сих пор в БСП не используются ... так и не был реализован.

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

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

>>  Как думаете, почему?

Для обратной совместимости.
В БСП "История изменений" появилась в те времена, когда в платформе ничего такого не было. Многие этим механизмом пользуются. При переходе с одного механизма на другой встаёт вопрос - что делать в переходный период. Оставлять работать оба механизма? Или отключать БСП-шный и терять историю?
11 timurhv
 
09.07.26
13:56
(9) да в БСП, версия само собой увеличивается, но сами данные не хранит, только контрольную сумму\хеш, по которой находит предыдущую запись с данными версии.

В версионировании платформы такого не должно быть, что вы написали, может баг был, либо не сделали слияние в основную таблицу с версиями (там отдельный метод для этого есть).
12 Dmitrii
 
гуру
09.07.26
14:08
UPD (10):

Про переход с БСП-шной истории изменений на историю данных в платформе.
На ИТС есть обработка по настройке истории данных и переносу версий: https://its.1c.ru/db/metod8dev/content/5969/hdoc
Выглядит она убогонько. Я бы потестил прежде чем в продуктиве такое запускать...
13 Dmitrii
 
гуру
09.07.26
16:42
Единственное, но очень важное преимущество БСП-шной истории изменений по сравнению с платформенной историей данных это наличие отдельных ролей, дающих право на чтение информации о версиях объектов. То есть можно создать отдельный профиль с этой ролью, группу доступа и включить туда пользователей, которым будет доступна история изменений по объектам.

В типовой ERP единственной ролью, обладающей правом чтения, изменения истории и перехода на версии истории является "Полные права". (другие конфигурации не смотрел, возможно там по-другому).
Так что, если условия эксплуатации предусматривают необходимость доступа к истории данных кому-либо, кроме админа(ов), то при переходе с БСП на платформенную историю, придётся заморачиваться и создавать новые роли или корректировать существующие.
14 timurhv
 
09.07.26
19:08
(12) чет я даже не задумывался что по версии можно получить документ\справочник как объект и делать разбор полетов почему у пользователя отработалось так, а не иначе)
15 xenos
 
09.07.26
20:09
(0) Возможно: разные команды делают
16 Волшебник
 
09.07.26
20:10
(15) Да, вероятно... Например, платформу пишут Си-шники, а БСП 1С-ники, но это не точно...
17 maxab72
 
09.07.26
20:47
"Например, платформу пишут Си-шники, а БСП 1С-ники, но это не точно..." неужели наоборот?!!
https://i.ytimg.com/vi/yHVmrCUYHjs/hqdefault.jpg
Компьютеры — прекрасное средство для решения проблем, которых до их появления не было.