Сжатие данных версионирования #655160

Приветствую! В типовой УПП есть код, суть проста - сжимает данные в версионировании. Вопрос - почему именно в запросе вытягивает поле ВерсияОбъекта, т.е. само хранилище значения? Ведь если переделать: ....        ХранилищеДанных = Новый ХранилищеЗначения(ДвоичныеДанные, Новый СжатиеДанных); .... то не надо будет тянуть в запросе. Дело вобще в том, что данный код "справляется" только с небольшими объёмами. Например вытянуть 500 тысяч несжатых записей уже валится. С доработкой - ему будет без разницы на объём. Почему именно так сделано? есть тайный смысл?

А зачем регламенту тянуть 500000 записей? Он в теории каждую нощь должон проходить.

Пока Истина Цикл Выбрать Первые 500

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

правда тогда надо распаковывать все версии когда одну надо получить...

этот регистр по-моему специально таким стремным сделан, у меня например большие сомнения в том что стоило датуверсии реквизитом а не измерением, тем более без индекса

Это всё вы правильно, меня интересует сам Запрос, ну нахрена тянуть в нём хранилище значения? Если ниже всё равно есть конструкция Прочитать - по сути и подтягивает хранилище

на больших объёмах данных сказывается, запрос очень долго выполняется, да и падает если совсем невмоготу

Как оптимизировать - понятно... ну это же типовое)

в этом и трабл. Регл задание было ограничено по времени, а т.к. запрос выполняется Долго из-за этого ненужного там поля - не всё успевал сжать, в итоге за полгода скопилось

Может я неправильный какой-то, но щетаю что код должен работать с учетом всяких форсмажоров, а не придерживаясь принципа "ну должно же быть меньше данных". Ошибку кто в запросе видит? или это специально сделано? тянуть хранилище значений

ну ладно, переделай у себя.

Я не вижу

Ну можно диапазонами сделать.

А вообще - попробуйте новый файл в архив ZIP добавить - он его с нуля пересожмет, так как ему словарь надо обновить и нужен цельный поток.

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

да, но 10 похожих XML очень похожи на 1 XML в архиве

эт логично, учитывая алгоритмы сжатия и внутренности XML

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

как делить общее хранилище будешь на независимые объекты для сериализации? хранить в хранилище структуру объектов?

А, все, вижу.

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

добавить пакет

XDTO

Тоесть?

в одном пакете можно хранить несколько объектов

хотя хз, надо проверять...)

Ну я и говорю, диапазоны.

Элемент с реквизитом типа anyType и maxOccurs unbounded, храни сколько хочешь чего хочешь

единственное, при изменении структуры метаданных - будет косяк

я себе допилил сохранение версии, очищая значения для полей с типом ХЗ. Все одно эти значения не сравниваются при сравнении версий