Задача такая: при операциях с объектами справочника ведётся протоколирование действий в регистре, и при этом одно из полей регистра - ссылка на объект. Это надо в дальнейшем чтобы открыть форму данного объекта.
Но вот проблема: тогда такие объекты справочников вообще нельзя удалить из конфигурации, т.к. на них в базе всегда присутствует хотя бы одна ссылка.
Где-то раньше уже встречался с технологией, с помощью которой можно превратить объект в строку и затем "развернуть" эту строку обратно в значение объектного типа (если такой объект ещё пристутствует в базе). Подскажите, как лучше всего это сделать в 8.2 (УИ).

ЗначениеВСтрокуВнутр(<Значение>)
ЗначениеИзСтрокиВнутр(<Строка>)

Не оно??

>  с технологией, с помощью которой можно превратить объект в строку и затем "развернуть" эту строку обратно

Строка(Ссылка.УникальныйИдентификатор()), МенеджерОбъекта.ПолучитьСсылку(Новый УникальныйИдентификатор(СтрокаУИД))

(1) +1

XMLСтрока

(1),(2),(4) - да, технологий много, но у них есть наверное какие-то отличия. Хочется узнать у практиков - как оно в реальных задачах себя ведёт, на какие грабли нарваться можно.

Например, (4), как мне кажется, лучше не использовать если хочешь на размере базы сэкономить. Т.е. в каждом случае есть свои "+" и "-".

(6) с чего бы это? самый быстрый и простой способ получить текстовое представление уид

вот так подскажешь и от автора еще и такую куйню в ответ получишь

(7)(8) А чё так резко сразу? Я просто обсуждение начал. Я же говорю что не использовал эти технологии.
Сейчас вот параллельно синтакс-помощник открыл, копаю все эти методы.
Если конкретно про XMLСтрока - да, он даёт GUID объекта для справочников, это гуд. Но вот проблема, когда мы будем обратно объект получать. Нам надо XMLЗначение заюзать, а оно требует первым параметром тип объекта, а мы его в общем случае не знаем, т.к. в строке можем сохранить сначение любого типа...

Аналогичная проблема и с (2) - типа объекта не знаем-то заранее...

Методом исключения остаётся ЗначениеВСтрокуВнутр. Пока получается, что только (1) для моей задачи подходит.

А в сторону навигационных ссылок (ПолучитьНавигационнуюСсылку) никто не смотрел?

"Но вот проблема: тогда такие объекты справочников вообще нельзя удалить из конфигурации, т.к. на них в базе всегда присутствует хотя бы одна ссылка."
Почему нельзя? Сделай измерение регистра, хранящее ссылку, ведущим. И удаляй сколько угодно.

По сабжу.
Юзай XMLСтрока + сохраняй тип объекта. В плане скорости и объема БД, пожалуй, лучшее решение. Кроме, конечно, Ссылки.
Получить навигационную ссылку задействует тот же самый механизм получения строкового представления УИДа + дополняет типом.
И еще, неизвестно, что будет с сохраненными тобой навигационными ссылками при очередном обновлении релиза платформы. Признай, будет обидно затерять историю.

(13) "Почему нельзя? Сделай измерение регистра, хранящее ссылку, ведущим. И удаляй сколько угодно."
Запись об операции с объектом должна остаться в регистре даже после того, как объект удалят из базы. Это протокол работы. Просто тогда уже нельзя будет открыть карточку объекта. А так, пока объект жив, надо иметь возмодность открывать его карточку.

(14) а, ну раз так, тогда конечно...

(13) Юзай XMLСтрока + сохраняй тип объекта.
Как правильно тип объекта тогда получить чтоб в обратно в XMLЗначение подставить? Я Строка(ТипЗнч(<ОбъектСсылка>)) пробовал - немного не то, что надо, выдаёт.

(13) В плане скорости и объема БД, пожалуй, лучшее решение.
Лучше чем ЗначениеВСтрокуВнутр, которое в одной строке всё хранит?

Предчувствую, что ещё и операции с документами в скором времени протоколировать надо будет. (13) для этого также подойдёт?

ТвояСтрока=Строка(СокрЛП(Объект.Ссылка));

:)::)

(18) не, походу и в правду ЗначениеВСтрокуВнутр оптимальнее будет

Чем мешает тупо ссылку хранить в ХранилищеЗначений?

Чем мешает тупо сделать Измерение УникальнымИдентификатором и в нем хранить Ссылку (чтобы контроль логической целостности не засекал ее), и еще реквизит в котором - Тип.

ПланыВидовХарактеристик вам для чего даны?

Да там задача вообще какая-то экзотическая. Из разряда Горе от ума. ТС почему-то пугают битые ссылки, которые могут возникнуть после удаления объектов из БД (что само по себе как-бы настораживаем, зачем удалять из БД объекты, да еще и с сохранением по ним истории изменений)

(24) Все вопросы к начальству - мы только исполняем его прихоти, а исполнить их надо.

(23) А ПВХ каким боком тут?

И никто так и не сказал как из объекта его тип получить в виде типа "СправочникСсылка.Номенклатура".

(27) ну, вроде через медатанные можно. вопрос в скорости

(27)

Оно:


Встроенные функции языка.ТипЗнч (Script functions.TypeOf)
Встроенные функции языка (Script functions)
ТипЗнч (TypeOf)
Синтаксис:

ТипЗнч(<Значение>)
Параметры:

<Значение> (обязательный)

Тип: Произвольный.
Значение, тип которого необходимо получить.
Возвращаемое значение:

Тип: Тип.

Описание:

Получает тип значения.

Доступность:

Тонкий клиент, веб-клиент, сервер, толстый клиент, внешнее соединение.
Пример:

Если ТипЗнч(ТекОбъект) = Тип("СправочникСсылка.Номенклатура") Тогда
   ...
КонецЕсли;



???

(29) Вот нахера здесь флудить, копи-пасты хелпа делать - тем более, что оно не работает. По крайней мере, в 8.2. В (16) я написал, что ТипЗнч не работает. Строка(ТипЗнч()) выдаёт тупо синоним.

(27),(28),(29) Походу вот так правильно тип получать:
ОбъектСсылка.Метаданные().ПолноеИмя();

http://zalil.ru/33490258

Вот вся твоя задача.

Конечно пичально, что ПустойСсылке нельзя задать UID, либо получить ее менеджер справочника, поэтому приходиться немного извращаться.

(33) Сенкс за пример. Ещё бы описалово какое к нему что там делать надо. Ну на свежую голову уже не сегодня смотреть буду.
У меня сейчас протоколируются также операции с регистрами сведений, и в дальнейшем документы будут протоколироваться. Такое Ваш подход потянет??

(32) Всё-таки не понял при чём тут ПВХ.....?

(32) Посмотрел Вашу конфу. UID-ы для ключей регистров сведений получить можно и таким же макаром сохранить в строку/развернуть обратно? Если нет, то тогда такой подход не годится.