mfp: Uptaking installation specific IDs

[fed]

Ну собственно они по похожей схеме и пошли. В предыдущей статье MFP, наисано что они для каждого элемента завели GUID:

Цитата:

To solve this we introduced a new guid property on all ID based elements and all root-elements: Origin. This property is set when an element is created, and remains static for the lifetime of the elements. It is the element's fingerprint. Besides enabling invariant IDs across releases for renamed elements the Origin property has proven valuable in data export scenarios, and rename scenarios of newly fine grained meta data (like forms).

То есть -они в каждой сущности AOD завели GUID. Именами не стали пользоваться чтобы дать возможность переименовывать объекты при рефакторинге (что полезно). А при инсталляции в конкретную систему, для каждого объекта, кроме GUID выдается еще и installation-specific id. Так что по хорошему, если хочешь в данных держать ссылку на идентификатор объекта, то надо заводить поле типа GUID, и туда этот Origin писать. Но для совместимости с предыдущими версиями, они приделали хитрую заплатку в импорт-экспорт, которая для полей с id объекта, пытается на ходу подменить его на GUID при эспорте и обратно на id при импорте...
Конечно я тут немножко додумал, возможно что использование GUID для ссылок на объекты не является best practice; Возможно по прежнему нужно использовать id с этой заплаткой на импорт/экспорт. Но все равно - ссылка по id, при таком подходе, постепенно станет пережитком...

[sukhanchik]

Цитата:

Сообщение от fed

Именами не стали пользоваться чтобы дать возможность переименовывать объекты при рефакторинге (что полезно).

Ну не согласен. С т.з. хранения ссылок на объекты в данных - конечно да, но я об этом и не говорил. Я говорил про штатную процедуру экспорта / импорта данных. Пусть она немного напряжется и при экспорте - вместо ссылки на объект подставит название объекта, а при импорте - обратно заменит на код.
По аналогии, как сейчас при импорте RefRecId пересчитывается.
Понятное дело - это не увеличит скорость экспорта / импорта. Зато он будет надежен на 100% (за исключением тех случаев, когда система не сможет догадаться, что для этого поля нужно делать замену. Однако, существующее решение аналогичной проблемы с RefRecId показало - что при желании - можно всего добиться).

Занести в бест практис указание использование спец типов для ссылочных полей.
И все будут стремиться их использовать.

[fed]

Цитата:

Сообщение от sukhanchik

Ну не согласен. С т.з. хранения ссылок на объекты в данных - конечно да, но я об этом и не говорил. Я говорил про штатную процедуру экспорта / импорта данных. Пусть она немного напряжется и при экспорте - вместо ссылки на объект подставит название объекта, а при импорте - обратно заменит на код.
По аналогии, как сейчас при импорте RefRecId пересчитывается.

Рискну предположить что:

• Имя, в среднем, длиннее GUID
• Имя может поменяться между версиями из за рефакторинга