Это абзац для тех, кто постоянно спрашивает "как это можно применить на практике?" (1). Мы пишем обмен между идентичными конфигурациями, основным требованием к которому является максимальная актуальность данных (задержка в пределах нескольких секунд). Из этого требования вытекает необходимость многопоточной обработки. Как следствие, требования к согласованности данных ослаблены до согласованности в конечном счете (2). Вследствие многопоточного режима, из источника могут отправиться две версии одного и того же объекта, которые на стороне получателя могут подхватиться двумя разными потоками разбора и какая версия окажется в итоге записанной последней - никому неизвестно. Это не соответствует принципу согласованности, пусть даже ослабленному. Поэтому, необходимо гарантировать запись именно последней версии объекта, с игнорированием предыдущих (3). Сделать это можно например так: в табличке, где лежат сырые данные для разбора - надо хранить номер сообщения, тип и идентификатор объекта. Соответственно, когда один из потоков будет подхватывать очередной объект для загрузки - нужно просто взять объект с максимальным номером сообщения, а остальным версиям поставить статус устаревших.
И в этой теории казалось бы все хорошо... Для объектных типов в качестве идентификатора идеально подходит гуид, для наборов записей регистров - гуид регистратора, константы идентифицируются типом (можно просто писать пустой гуид 00000000-0000-0000-0000-000000000000)... но черт возьми, набор записей регистра сведений, не подчиненного регистратору не имеет идентификатора!
Мы не могли позволить, чтобы это обстоятельство похоронило весь наш быстрый и красивый обмен, поэтому разработали схему, позволяющую назначить набору записей идентификатор и использовать его как гуид этого набора.
Почему мы идентифицируем именно наборы
Во-первых, необходимо пояснить почему мы будем идентифицировать гуидом именно набор записей, а не конкретную запись. Дело в том, что мы в первую очередь ориентируемся на таблицу изменений регистра, а регистрация происходит не по всем измерениям, а по тем, на которых стоит "основной отбор". Плюс, в состав регистрации может включаться или не включаться период (галочка Основной отбор по периоду). Таким образом, независимо от того, с каким отбором был записан набор записей - регистрация изменений произойдет с отбором по тем полям, которые участвуют в основном отборе, а в нем могут участвовать не все измерения. Давайте договоримся далее называть эти измерения и период - основными изменениями.
Вообще, регистр сведений весьма вариативная сущность, которая может интересно реагировать если потыкать в нее палкой на внешние воздействия. Можно, например, припомнить такие случаи:
- записываем набор с одной записью - выгружаем 100500 наборов. Например, когда при записи вы установили отбор только по складу, добавили в набор одну запись, но из регистра удалится 100500 записей с этим складом и все они зарегистрируются для изменения.
- менее очевидный пример: при записи записываем 100500 наборов - выгружаем один. Такое возможно, если при записи вы заполняете отборы по всем измерениям, записываете много наборов, но с одним и тем же складом, а выгружать нужно только один набор потому что основной отбор стоит только на поле "склад" (иными словами, для обмена регистрируется набор с отбором только по складу).
Возвращаясь к идентификаторам - наша цель использовать их для обмена. Соответственно, идентифицировать имеет смысл не что-нибудь, а наборы именно с отбором по основным измерениям.
Итак, приступим к прикручиванию идентификатора. План такой:
- Заводим общий реквизит типа УникальныйИдентификатор и подпиской заполням его.
Шутка. Хотя, мы рассматривали такой вариант реализации, однако в следствие необходимости поддерживать непротиворечивость в рамках одного набора записей (набора с отбором, соответствующим основному отбору) при принципиальной неизвестности того, с каким набором производится запись - это могло обернуться очень запутанным кодом и существенными проблемами с производительностью.
Сигнатура, корзина и идентификатор
Итак, для начала нам нужно ввести понятие сигнатуры и корзины.
Сигнатура - это данные (строка, число), однозначно идентифицирующие что-либо. Например, сигнатура документа в 1С - это его тип и гуид. Сигнатура человека - это его ДНК. Сигнатура автомобиля - вин-номер. Продолжать можно долго, идея надеюсь понятна. Сигнатурой набора записей, его ДКН, естественным образом является набор значений основных измерений.
При этом, эта сигнатура будет обладать следующими замечательными качествами:
- однозначность и непротиворечивость: от одного набора записей можно прийти к одной и только одной сигнатуре. Иными словами, сигнатура и значения основных измерений связаны друг с другом один-к-одному и имея один из них можно однозначно получить другой.
- независимость от условий в которых выполняется алгоритм. Иными словами, алгоритм будет давать одинаковый результат на разных базах, в разное время, без интернета и т.п.
Отметим также, что сигнатура - это довольно длинная строка, строгого ограничения которой по длине гарантировать невозможно, а следовательно по ней невозможно строить индексы, следовательно быстро искать. Следовательно, сигнатуры нужно разложить на кучи, поиск которых будет осуществляться очень быстро, а поиск внутри кучи - тоже не долго из-за небольших размеров самой кучи.
Корзинами будем называть хранилища сигнатур, при этом сигнатуры будут раскладываться по корзинам не абы как, а по жесткому правилу, обеспечивающему повторяемость. Например, если есть сигнатуры ААА, ААБ, БАА и ВВВ - то таким правилом может быть, например, взять первый символ. Т.е. мы однозначно определим, что в корзину А попадают сигнатуры ААА и ААБ, в корзину Б - сигнатура БАА, а в корзину В - сигнатура ВВВ. (4)
Все, понимания двух идей: сигнатуры и корзины, достаточно чтобы приступить к практическим действиям, давайте сформулируем алгоритм конкретнее.
1. Основные изменения представим строкой вида <Название "Тип"="ЗначениеТипа" "Значение"="ИдентификаторЗначения">. Например:
- <Период Тип="Дата" Значение="19.05.2019 19:02:08">
- <ДокументОснование Тип="Неопределено" Значение="Неопределено">
- <Номенклатура Тип="CatalogRef.Номенклатура" Значение="6F9619FF-8B86-D011-B42D-00CF4FC964FF">
- <Характеристика Тип="CatalogRef.ХарактеристикиНоменклатуры" Значение="00000000-0000-0000-0000-000000000000">
На что обратить внимание:
- Если кому-то нравится использовать псевдо-json вместо псевдо-xml синтаксиса или придумать полностью новый формат записи - это на скорость не влияет, главное чтобы не получилось что строка "11.02.2019 12:00:00" и дата "11.02.2019 12:00:00" - это одно и тоже
- Также можно креативить на предмет наличия значения типа Неопределено и пустых ссылок.
- Тип здесь - это не тип поля, а тип значения. т.е. независимо от того сколько типов может лежать в этом поле - мы пишем только тот, который реально лежит.
- Неопределено и пустая ссылка - это не одно и тоже и оба значения могут встречаться в полях множественного типа.
- Для получения строкового представления типа - мне известен один способ: XMLТипЗнч.
- Лучше добавить ко всему этому название самого регистра, поскольку при некоторых условиях это может сильно облегчить нам жизнь, об этом пойдет речь ниже.
2. Далее просто конкатенируем (сцепляем) полученные строки и получаем саму сигнатуру:
<РегистрСведений.НазваниеНашегоРегистра><Период Тип="Дата" Значение="19.05.2019 19:02:08"><ДокументОснование Тип="Неопределено" Значение="Неопределено"><Номенклатура Тип="CatalogRef.Номенклатура" Значение="6F9619FF-8B86-D011-B42D-00CF4FC964FF"><Характеристика Тип="CatalogRef.ХарактеристикиНоменклатуры" Значение="00000000-0000-0000-0000-000000000000">
Чтобы поберечь нервы ресурсы СУБД - ее можно поджать каким-нибудь алгоритмом сжатия (методы, не выходящие за пределы 1С гуглятся на ИС), "качество" сигнатуры при этом не пострадает, но глазами ее читать станет невозможно.
3. Далее надо разобраться с корзинами. Для них создадим отдельный справочник: один элемент справочника = одна корзина. Идентификатор корзины = ГУИД элемента справочника. Чтобы определить идентификатор корзины по сигнатуре - нужно ее хэшировать алгоритмом MD5 (5). В табличной части сделаем две колонки: сигнатура и ГУИД. В первую колонку будем складывать сигнатуры наборов записей, а во вторую идентификаторы этих наборов (просто Новый УникальныйИдентификатор). Далее, в корзине (табличной части) перебираем все строки - ищем есть ли там наша сигнатура, если нет - добавляем строку и назначаем ей новый гуид, который и будет идентифицировать наш набор записей, если есть - берем ранее созданный.
Вот в общем то и все.
Производительность
В рамках конкретно моей задачи, я предполагаю, что гуид поможет идентифицировать изменения "одного и того же" набора записей. Т.е. в нашем случае направление всегда одно: от набора записей к ее идентификатору. Такая однонаправленность позволяет нам иметь довольно простую логику и неплохую производительность: при наличии набора (на самом деле записи в таблице изменений) - получаем сигнатуру набора и идентификатор ее корзины без обращений к "медленным" ресурсам, далее вычитываем из БД соответствующий элемент справочника по его ссылке и перебираем довольно короткую таб.часть (на практике более одной записи есть в считанных единицах элементов). Все это не слишком затратное мероприятие.
Перейти же от идентификатора набора к самому набору тоже можно, но это будет сложнее как с точки зрения производительности так и с точки зрения сложности кода: сначала придется искать по значению идентификатора в табличной части (это будет дольше, даже если положить на это поле индекс, кстати, если не планируется "обратного алгоритма" - делать этого не нужно и даже вредно), далее читать соответствующую сигнатуру, парсить ее, восстанавливать типы значений и далее создавать набор.
А что если...
... изменить в наборе записей значение одного из измерений. Кодом такое сделать не получится, а если провернуть это через пользовательский интерфейс - в таблице изменений появятся две записи: старого набора и нового набора. Одна будет сигнализировать об удалении старого набора, вторая - о появлении нового. Сигнатуры так же окажутся разными: на удаленный набор своя и на новый набор своя. В этом смысле наш механизм работает абсолютно "синхронно" с платформой.
... сделать состав измерений, включенных в сигнатуру, не соответствующим основным измерениям. Тут все сильно зависит от ваших целей. Можно, например, включить в сигнатуру все измерения, в этом случае идентифицироваться будут не наборы записей, а индивидуальные записи, но для целей обмена делать так смысла нет. В большинстве случаев основной отбор и так стоит на всех измерениях. Можно включить в сигнатуру меньше полей, чем в основном отборе - в этом случае идентифицироваться будут бОльшие наборы записей, если пофантазировать - можно придумать специфический кейс, но в целом мне думается что все-таки имеют смысл только два варианта: по всем измерениям и по измерениям основного отбора
... изменился состав основного отбора. Это дорого вам обойдется ) Вам придется писать постобработку, которая перечитает все идентификаторы наборов записей с сигнатурой, составленной по "старым правилам" и соответствующим хэшем, и запишет те-же самые идентификаторы с сигнатурой составленной "по новым правилам" с новыми хэшами в новые корзины. Тут то нам сильно облегчит жизнь добавление наименования регистра в сигнатуру набора (6).
... в двух узлах почти одновременно запишут одинаковые записи - у них будет одинаковая сигнатура, одна и таже корзина, но разные идентификаторы. Такие конфликты разрулить автоматически не составит труда. Более того, для этого не нужно иметь сложной синхронизации разных баз, а сделать это можно независимо в разных узлах (например, если предположить, что сгенерированный идентификатор из базы 1 отправился в базу 2, а из базы 2 в базу 1). Для этого нужно иметь специфическую логику в обмене (7).
(1) На самом деле, я считаю, что "стоящая мысль" достойна быть озвученной, независимо от того, видно ли для нее достойное применение. Если 100 человек не знают как применить что-то на практике - это не означает, что не найдется 101-й, который давно мучается соответствующей проблемой. Математики не дадут соврать.
(2) Всем кто активно пишет обмены - рекомендую ознакомиться с концепцией обмена с гарантией согласованности в конечном счете. Применять ее на практике или нет - можно обсуждать, но знать о ней стоит однозначно.
(3) Вопрос о том, важна ли последовательность объектов или важны только сами объекты, весьма неоднозначен и имеет глубокие теоретические корни. Можно сформулировать два более конкретных вопроса, ответы на которые имеют ключевое значение для любого обмена:
- можем ли мы нарушить последовательность записи разных объектов? Имеет ли при этом значение одного типа объекты или разного?
- можем ли мы нарушить последовательность записи одного объекта? (т.е. из версии 1 перевести его в версию 3, минуя версию 2, в которой он пребывал в источнике)
Мы более-менее нашли для себя ответы на эти вопросы. Сразу оговорюсь, что тема довольно скользкая и мы не претендуем, что эти ответы безупречно подходят даже для РТ, не говоря уж о любых других конфигурациях. Итак:
- можем ли мы нарушить последовательность записи разных объектов? да, но только при условии что мы имеем обмен между идентичными конфигурациями и движения по регистрам передаем "как есть", без перепроведения документов. Все что может помешать такому ответу - противоречит принципу, принятому при разработке типовых конфигураций 1С: "если документ не менялся - результат проведения при перепроведении меняться не должен" (sic!). Иными словами, у нас может быть какая-то проверка по ссылке (например попытка проверить ставку ндс у номенлатуры, которой еще нет в этой базе), но это будет означать, что такая проверка может изменить результат проведения документа при изменении номенклатуры, что противоречит сформулированному принципу.
В крайнем случае - такая ситуация окончится исключением и автоматическим повтором загрузки, которая, после загрузки номенклатуры, окончится успехом с какой-то попытки. - можем ли мы нарушить последовательность записи одного объекта? нет, но мы все равно так сделаем ) Строго говоря, нет принципа по которому результат записи объекта не должен зависеть от предыдущего состояния этого объекта. Например, документ может быть создан только в статусе "новый", из него переведен только в статус "проверен". Соответственно запись в приемник сразу в статусе "проверен" окончится неудачей. Но есть два но: первое - типовой механизм регистрации объектов "съедает" подобные случаи, второе - таки есть разница между записью пользователем и записью в режиме обмена данными. Соответственно, любые подобные случаи мы отлавливаем "по факту" и выносим проверку за пределы обмена данными.
(4) Вообще, весь этот алгоритм - это творчески преработаный алгоритм Хэш-таблиц. Так что это компьютер-саенс, бэст-практикс и все такое, а не "костылей понаставили"
(5) На самом деле не обязательно именно так. Можно придумать любой свой алгоритм, вплоть до такого: взять строку в двоичном коде, разбить на 128 участков, из каждого взять по первому биту - слепить их в гуид, главное чтобы он обеспечивал повторяемость. Но такой алгоритм не будет давать хорошего распределения, потому что на определенных позициях будут всегда будут определенные символы (например первые символы очень часто будут повторяться вследствие вставки названия регистра), что неизбежно сделает одни куче больше других, а MD5 дает хорошее распределение и вероятность появления больших куч крайне мала.
(6) Вопрос о том, требуется ли идентифицировать наборы разных регистров, имеющие одинаковые значения основных измерений одним идентификатором или разными упирается в вопрос о том, какую постобработку изменения метаданных регистра вы хотите писать.
Если идентификатор будет один - алгоритм постобработки должен буть запущен после изменения состава основных измерений и он должен уметь "расщеплять" записи, т.е. для записей неизменного регистра идентификатор останется тот же, а для записей измененного регистра идентификаторы будут новые и их нужно раскидать по всем зависимым местам, при этом понимая где мы имеем дело с идентификатором набора неизменного регистра, а где - измененного.
Если же идентификатор зависит от имени регистра - алгоритм должен запуститься как в случае изменения состава основных измерений, так и в случае изменения имени регистра (от последнего нас бы избавило знание идентификатора метаданных регистра, но нам его достать негде. или есть где?..). Но этот недостаток компенсируется отсутствием необходимости расщеплять и замещать: изменится только сигнатура и корзина в которой она лежит, идентификатор останется тот же, что избавит от необходимости заменять его по другим местам.
Хорошего ответа на этот вопрос нет - каждый подход имеет свои минусы. Вероятно, если получить идентификатор регистра (как объекта метаданных) и идентификаторы его основных измерений (в том же смысле) - эту проблему можно разрешить. Если кто-то предложит способ как это сделать - я возьмусь протестировать предложенный подход и сообщу результаты. Пока же остается писать длинную инструкцию на случай, если кто-то будет трогать регистр "после нас", разрабатывать отдельный механизм, в котором "запомнить" количество и порядок измерений, задействованных в сигнатуре каждого регистра и если оно вдруг изменилось - сыпать исключениями (вплоть до отказа от начала сеанса) и надеяться, что "после нас" не посчитают это странной фигней, которую можно игнорировать.
(7) Во-первых для справочника содержащего корзины, мы никогда не затираем таб.часть, а только добавляем новые записи, во-вторых, при назначении идентификатора первой сигнатуре в корзине - его можно сделать идентичным идентификатору корзины (это не привнесет никаких гарантий, просто избавит от 99% дополнительной нагрузки на БД), в-третьих, если в элементе оказалось две строки с одинаковой сигнатурой - из двух конкурирующих гуидов выбрать тот который меньше, а тот что больше пометить как неактуальный, в-четвертых, везде, где мог быть записан конкурирующий гуид - исправить его на нужный. Все описанное должно происходить в первые же секунды после создания соответствующего набора, и "плохой" идентификатор не успеет слишком "расползтизь" по базе, однако, если включить паранойю рассмотреть самый негативный сценарий - "плохой" идентификатор может закэшироваться где-то в повторноиспользуемых значениях и продолжить свое существование (собственно для последующих разборов полетов и предлагалось не просто удалять, а помечать их неактуальными). Честно признаюсь, у меня реализовано только "во-вторых" из написанного в этом пункте и полет пока нормальный.
