Наткнулся на баг в 1с 7.7. Или это не баг, а специально уложенные грабли.

Если несколько раз подряд делать сериализацию таблиц значений с одинаковым содержимым, то получаемые строки могут отличаться (при сравнении на равенство). При этом полученные путем десериализации объекты через обратную функцию ЗначениеИзСтроки{Внутр} - одинаковы, как и должно быть.

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

Путем анализа текстовых строк выгрузки обнаружилось, что строки колонок таблицы могут выгружаться в разном порядке. При этом дополнительно хранится порядок строк, что обеспечивает корректное восстановление(десериализацию).

Но вот возможности использовать сериализацию для сравнения таблиц на идентичность - теряется.

Такая вот загогулина, панимаишь..

Занятно.

И что?

Сделай свою сериализацию. С шахматистками и карточной настольной игрой.

(3) А что шахматистки в это деле как то иначе?

(0) Ты особенности реализации ТЗ в платформе 1С, написанной на C++ (термины указатель, динамический список что то говорят?) понимаешь?
Это не баг, это фича

Можно сортировать или копировать строки в новые ТЧ и вот они новосозданные будут (должны) одинаковы

(0) Спасибо! Будем знать и сравнивать таблицы через сворачивание.

(4) Да. У них есть правило - тронул ходи...

(5) Да я понимаю. Как и понимаю, что они ничего не должны кроме того, что написано в документации. А в документации повторяемость не гарантируется.

В общем, если очень надо и очень хочется сохранять таблицу в строке, пригодной для сравнения - то можно использовать для сериализации объект ИндексированнаяТаблица из 1с++ и его родные методы ВСтроку и ИзСтроки. Метод ВСтроку дает пригодную для последовательных сравнений строку, в отличие от платформенной функции.

А на 8 кстати таже проблема?

(10) В восьмерке ЗначениеВСтрокуВнутр объявлено устаревшим, и его не рекомендуют использовать в любом случае.
А вообще, конечно, вопрос интересный. Существует ли в 1с документированный способ сериализации объекта, где бы гарантировалась повторяемость при сериализации одинаковых копий объекта (не ссылок на один и тот же объект). Хотя бы в рамках одного сеанса.

(11) тут недавн ветка была как сравнить тз.
И угадайте какой метод был предложен...

Хорошо сказано "строки колонок таблицы", пора новый термин вводить "колонки строк" :-)

(11) в json

(13) Там именно "строки колонок" хранятся, в сериализации. Гляньте внутрь. Данные хранятся сгруппированные по колонкам. То есть сначала первая колонка (все строки), потом вторая.. и так далее. А потом ещё некий служебный тег - единый порядок строк в этих колонках. Нифига не логично, но так оно есть.

(15) Верю, но то что данные хранятся по колонкам, это не значит, что хранятся "строки колонок", хранится колонка, а уж в каком порядке это другой вопрос...

(16) Вопрос терминологии) Логично было бы предполагать, что колонки выгружаются в натуральном порядке возрастания номеров строк, а вот фигвам, они выгружаются как хочет платформа, а для компенсации этого дополнительно пристегивается список перестановки строк)

+(16) Ну и, да простит меня автор, всегда считал, что сравнивать большие текстовые куски, что нам и выдает значениевстрокувнутрь() признак плохого стиля :-( . Максимум на что эта штука годится обмен между базами быстро пишется и то в случае, если в ТЗ скидывать ТОЛЬКО простые типы: число, строка, дата...

(18) Ну, сравнивать таблицы "в лоб" по строкам и столбцам тоже стиль так себе. Может это и правильно, но мееееедленно.

(19) хеш считать

(19) Свернуть() работает достаточно быстро

Можно свое ЗначениеВСтроку сделать. Всего-то шесть строк

резстрока="";
для каждого стр из тз цикл
    для каждого колонка из тз.колонки цикл
        резстрока=резстрока+строка(стр[колонка.имя]);
    конеццикла;
конеццикла;

(21) Свернуть считает итоги, а идентичность таблиц подразумевает не только идентичность итогов

(14) А что, формат json однозначно определяет отображение объекта в сериализованную строку? Вряд ли. Есть пробельные, форматирующие элементы, комментарии, которые при чтении игнорируются, а при записи могут быть добавлены. Кроме того, в xml например явно прописано, что атрибуты объектов могут сохраняться в произвольном порядке, не обязательно в порядке их добавления или в алфавитном. Скорее всего, подобное и в json есть.
Так что, формата, где бы декларировалась и поддерживалась детерминируемая повторяемая сериализация в 1с похоже нет(

(22) такое не прокатит. в этом варианте будет представление значения. например, в двух таблицах будет одно и то же представление "основной договор", но договора при этом - разные...

(15) Наоборот логично, если учесть, что в таком виде строка лучще сжимается.

(17) Думаю, что выгружаются так, как лежат в памяти.

(25) ну можно добавить проверку на тип значения.  Если тип справочник - выгружать код+представление.  Если документ - выгружать Вид()+ДатаДок+НомерДок.

(19) это во-первых правильно, во-вторых не медленно ни фига
в-третьих, это единственный вариант, при котором можно сразу сформировать вменяемый репорт о расхождениях в сравниваемых таблицах:  в какой строке, в какой колонке, в чём различие.

(25) угу кривая хэш-функция

(28) зависит от условий задачи
если выявлять расхождения не надо то просто делаем два хэша и сравниваем их
если нужны расхождения то да тупо в лоб сравнивать