Объект "ХранилищеЗначения" известен в 1С, начиная с 8.0 и, казалось бы, прост, понятен, изучен вдоль и поперёк. Но иногда возникают вопросы, касающиеся работы с хранилищем, и данная публикация (по сути, краткий антисклерозник) призвана зафиксировать ответы на некоторые из них.
Хранилище значения (далее ХЗ) представляет собой данные, полученные кодированием и, при необходимости, сжатием входных данных с помощью 32-х битного алгоритма Deflate, он же Deflation (о размерах сжатия см.ниже).
Хранение
Данные типа ХЗ могут храниться и обрабатываться в таблицах СУБД, в рамках модели данных 1С являясь реквизитами шапки, табличных частей, регистров, бизнес-процессов, задач; ресурсами регистров сведений, параметрами сеанса, общими реквизитами, функциональными опциями (на основе хранимых данных типа ХЗ). То есть, ХЗ может быть типом только для поля, хранящегося в базе (т.е. в отчётах, обработках, реквизитах/параметрах форм этого нет).
С точки зрения наиболее распространённых СУБД ситуация следующая.
SQL
ХЗ хранятся в полях IMAGE (тип данных SQL2003: BLOB), это традиционный тип LOB-хранилищ для SQL Server, в котором можно хранить как текстовые, так и двоичные данные. Хранит двоичное значение переменной длины до 2 147 483 647 байт (т.е. 2 Гбайт или 2^31 байт), механика выделения места под страницу таблицы и таблицу вообще варьируется в разных версиях SQL и разных настройках. Столбцы типа IMAGE (как и родственная ей TEXT) имеют множество ограничений на способы использования - например, нельзя создавать индекс по столбцу типа IMAGE, есть особенности при работе с хранимыми процедурами. При этом, значениями типа IMAGE можно манипулировать при помощи функций DATALENGTH, PATINDEX, SUBSTRING, TEXTPTR и ТЕХTVALID, а также команд READTEXT, SET TEXTSIZE, UPDATETEXT и WRITETEXT. Преобразования типа implicit conversion (а именно на них опирается 1С) возможны из IMAGE в: binary, varbinary, timestamp (логично, сплошь двоичное по сути), в него ещё можно из char и varchar. Сам этот тип усердно НЕ рекомендуется к использованию в скуле, но до сих пор есть. Последние несколько версий платформ для хранения ХЗ в MS SQL используют тип VARBINARY(MAX). IMAGE является устаревшим и используется по накатанной из старых версий платформ.
PostgreSQL
ХЗ хранятся в полях bytea (ссылка стандарта на тот же тип данных SQL2003: BLOB). Для хранения нужны 4 байта плюс реальный размер битовой строки (т.е. 4 бита сверх трёхбитового заголовка самого потока Deflate). В двоичных строках можно хранить байты с кодом 0 и другими «непечатаемыми» значениями (обычно это значения вне десятичного диапазона 32..126). Обрабатываются они как двоичные в чистом виде (не как текстовые, не по языковым стандартам). Тип bytea поддерживает два формата ввода и вывода: "шестнадцатеричный" и традиционный для PostgreSQL формат "спецпоследовательностей". Входные данные принимаются в обоих форматах, а формат выходных данных зависит от параметра конфигурации bytea_output; по умолчанию выбран 16-ричный. Кстати, известно, что оный формат был введён в PostgreSQL 9.0; в ранних версиях он может и не работать - интересно, учитывает ли это платформа? По утверждению ИТС, содержит значение, если его тип "Хранилище значения", или последовательность байт нулевой длины в противном случае.
Кстати, если говорить об интеграции и внутренних передачах таких значений между системами - в Visual Basic, например, эти значения преобразуются в одномерные массивы Byte(). Этот массив имеет диапазон Byte (от 0 до length 1), где length — число байтов в значениях SQL Server binary, varbinary или image.
ХЗ не может фигурировать в составных типах. Однако, есть несколько способов обойти декларативный запрет и даже использовать в функционале: хранилище может быть определяемым типом, но только одиночным значением во всём типе (т.е. не составным), и может фигурировать как тип ПВХ (через определяемый), но тоже только одиночным. Возможно, именно так проявляется необходимость объявления требуемого места в таблицах СУБД.
Переменные и формы
Данные типа ХЗ могут храниться в переменной языка 1С в контексте выполнения , т.е. размещаться в поименованной области памяти. Ограничений на использование нет ни по типам модулей (общие, глобальные, модули объектов, менеджеров, форм, команд и т.д.), ни по исполнению на клиенте/сервере. Конструируется на сервере, а как переменная живёт и на клиенте. Является одним из традиционных способов рабоче-служебной сериализации данных, в т.ч. безотносительно степени сжатия, и передачи в сжатом виде. Само понятие "сериализация" в СП 1С привязано именно к ХЗ, т.е. возможность помещения значения в ХЗ терминологически и было долгое время сериализацией. В ХЗ может быть помещено любое значение, про которое это указано в СП, и любая универсальная либо обменная коллекция, состоящая только из сериализуемых значений на любую глубину вложенности.
Программное использование ХЗ не вполне прозрачно и очевидно. Так, чтение реквизита объекта типа ХЗ выполняют традиционно в "ПриЧтенииНаСервере", а запись - в "ПередЗаписьюНаСервере", потому что в данных формы ХЗ официально вроде как нет. На самом деле, возможны варианты. ХЗ может быть присвоено реквизиту формы (в т.ч. табличному реквизиту коллекции) с типом "Произвольный". Ряд ситуаций работы с ХЗ в клиентском контексте, несмотря на утверждения СП, не компилируется, т.е. для уверенности в результате лучше всё делать на сервере. Очевидно, что не стоит работать с ХЗ как с переменной модуля формы.
Находясь в коллекциях формы, НЕ может обрабатываться на клиенте (чтение/запись), но не теряется при передаче формы на сервер и обратно, сбросе кэша, переинициализации контекста. Может передаваться как параметр формы без его явного объявления в т.ч. в другую форму; может быть ключевым параметром формы - всё это корректно работает.
В обычных формах реквизит недоступен к выводу в список и на форму, но может фигурировать как значение реквизита формы произвольного типа или через определяемый (вообще в реквизитах только через него и можно "обернуть"), и как значение колонки таблицы/дерева значений произвольного типа.
В управляемых формах аналогично. Формально, выводятся сообщения, что "в данных формы нельзя", но если обёрнуто в произвольный реквизит, то хранит, обрабатывает и показывает.
ХЗ может фигурировать как аргумент в методе обычной и упр.формы Закрыть(хз), и корректно передаётся; может и фигурировать в ОписанииОповещения как результат закрытия формы, ранее открытой с указанием такового.
Важно: между сеансами для формы с авто (а равно и не-авто) сохранением значений произвольный реквизит с таким значением НЕ сохраняет!
Современное использование ХЗ поражает нетривиальностью - так, например, в БСП значения типа ХЗ хранятся и обрабатываются в параметрах СКД отчётов, и на этом основана целая механика работы. Вопросы трансляции и исполнения СКД, в чьих полях так или иначе фигурируют ХЗ или заявлена типизация ХЗ - тема отдельного исследования.
Кодинг
Может возвращаться на клиент как результат функции, параметр процедуры, может передаваться как параметр с клиента и вообще как аргумент, в т.ч. с ключевым "Знач", кроме, конечно, модулей повторного использования.
Помимо сериализации, ХЗ предлагает в конструкторе управление сжатием (это нелинейно эквивалентно степеням сжатия, т.е. "быстрое", "обычное", "максимальное", а не статике/динамике по Хоффману).
Поскольку нет возможности напрямую замерить объём, занимаемый переменной 1С в памяти, рассматривать приходится строки и двоичные данные, полученные из них. ХЗ удобно обрабатывать через xml
// из строки в ХЗ
хз=XMLЗначение(Тип("ХранилищеЗначения"),ИсходнаяСтрокаBase64);
// из ХЗ в строку
ИтоговаяСтрокаBase64=XMLСтрока(ХЗ);
стро1=XMLСтрока(хз);
// эквивалентно
стро2=СериализаторXDTO.XMLСтрока(хз);
// тогда как, например, такая сериализация гораздо больше по размеру
стро3=ЗначениеВСтрокуВнутр(хз);
Важно понимать, что ХЗ это не значение, а указатель на область памяти. Они всегда разные, поэтому ни сравнение, ни поиск, ни отбор (в т.ч. в запросах) применять нельзя. Указатель равен сам себе лишь в рамках конкретного оператора-конструктора (и, кстати, в этом случае по нему работает, например, поиск в универсальных коллекциях). Так, например, если "А=хз; Б=А;", то А будет равно Б. А для сравнения именно значений следует действовать так (причём это не будет распаковкой как "расжатием"):
СодержимыеВнутриХЗРавны=(XMLСтрока(хз1)=XMLСтрока(хз2));
и это не зависит от наличия и степени сжатия в их конструкторах. Кстати, после применения конструктора определить степень сжатия можно лишь преобразованием в двоичные данные и анализом первых битов потока.
Так вот, размер "как есть" мы можем узнать, либо создав объект метаданных (например, справочник с единственным реквизитом типа ХЗ) и получив размер таблицы методом ПолучитьРазмерДанныхБазыДанных, либо опосредованно, через строку и двоичные данные (учитывая неизбежно прибавляемое), так:
Размер=ПолучитьДвоичныеДанныеИзСтроки(XMLСтрока(хз)).Размер();
// или так
Размер=Base64Значение(XMLСтрока(хз)).Размер();
Это не годится для абсолютных замеров (так, один символ латиницы, т.е. по идее 1 байт, и символ кириллицы, 2 байта, дают одинаковые 32 байта на выходе), но годится для относительных прикидок. Так, вызов без прямого указания "СжатиеДанных" всегда даёт значение большего (и иногда существенно большего, в разы) размера, чем с любым сжатием. На малых размерах сжатие не даёт заметного эффекта при любом аргументе. В СП сказано, что аргумент по умолчанию для объекта "СжатиеДанных" равен 1, но сжатие без его указания и с явным указанием даёт разные размеры, до десятков и сотен байт. На средних объектах (например, строки 500-1000 символов) сжатие со степенью выше 3-4 даёт примерно одинаковые итоговые размеры, т.е. эффективность одинаковая. Наряду с этим, в ряде старых релизов конструктор без сжатия даёт меньший итоговый размер.
Деструкция этого указателя тоже имеет нюансы.
// правильные способы
хз="";
хз=Неопределено;
хз=Null;
хз=Новый ХранилищеЗначения(Неопределено);
хз=Новый ХранилищеЗначения(Null);
// неправильный способ
хз=Новый ХранилищеЗначения(""); // занимает как минимум на 3 байта больше, чем остальные
В таблицах/деревьях значений с явно объявленной колонкой может использоваться везде, кроме запроса (не помещается в ВТ), не воспринимается как аргумент запроса, даже как &ПараметрТипаХЗ в секции "ВЫБРАТЬ". Что, учитывая известное про СУБД, не вполне логично.
При копировании объекта с реквизитами, содержащими ХЗ, ни интерфейсно, ни программно, эти значения НЕ наследуются, не копируются.
Если некое значение, упакованное в ХЗ, подпадает под RLS, то логика следующая - платформа всегда вначале выполняет неявную распаковку, либо рассматривает сделанную в коде явную; а затем накладывает ограничение, так что RLS применится именно для уже распакованного значения, спровоцировать тут ошибку ни разу не удалось.
Из интересных публикаций рекомендую эту.
Поскольку в современных метаданных конфигураций реквизит типа ХЗ где-нибудь точно наличествует, а также фигурирует в коде, то вопрос занимаемого им места актуален. В связи с этим было бы интересно исследовать рост места, занимаемого таблицей, состоящей исключительно из ХЗ, а также сравнить эффективность работы "СжатиеДанных" и основанного на том же Deflation объекта "ЗаписьZipФайла", пробуя разные значения УровеньСжатияZIP (естественно, при МетодСжатияZIP = "Сжатие").
Возможно, этот привычный и вроде бы простой объект, Хранилище значения, преподнесёт (особенно на больших данных и нагрузках) ещё некоторые удивительные сюрпризы.
P.S. Опыты проводились на 8.3.6.2237 и 8.3.16.1224.
