![]() |
#1 |
Участник
|
mfp: Uptaking installation specific IDs
Источник: http://blogs.msdn.com/b/mfp/archive/...cific-ids.aspx
============== In Microsoft Dynamics AX 2012 we have solved the element id problem. The solution is outlined in this post. The solution consists of major changes both having an impact on existing AX 2009 and AX 4 solutions:
![]() ============== Источник: http://blogs.msdn.com/b/mfp/archive/...cific-ids.aspx
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору. |
|
![]() |
#2 |
Administrator
|
Хм... разные ID у одного и того же объекта будут в разных инсталляциях. Допустим.
У поля будет свойство RelatedTable. Это хорошо, когда ссылки на одну таблицу (типа InventSettlement -> InventTrans, VendTransOpen -> VendTrans). А когда разные - предлагается создать группу полей. И ЧТО ЭТО ДАСТ? Дальше. А коды других объектов уже в БД не будут храниться? Ну там типа методов экспорта платежных поручений в способах оплаты. Мне вот интересно - а насколько сложно сделать элементарную вещь: Пусть в файле экспорта данных вместо ID объектов подставляется реальное название объекта. Вместо вот этих вот 16-ричных цифр - просто название. Все! Это же решит проблему. Никто не переносит данные между принципиально разными приложениями. Ну или переносит с пониманием того, чего делает. А вот перенос данных между одинаковыми приложениями - легко. Ну и пусть будет идентификация по именам! Только для переноса. А ID-шники в общем-то и сейчас сильно зависят от инсталляции (за исключением конечно стандартного функционала)
__________________
Возможно сделать все. Вопрос времени |
|
![]() |
#3 |
Moderator
|
Ну собственно они по похожей схеме и пошли. В предыдущей статье 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).
Конечно я тут немножко додумал, возможно что использование GUID для ссылок на объекты не является best practice; Возможно по прежнему нужно использовать id с этой заплаткой на импорт/экспорт. Но все равно - ссылка по id, при таком подходе, постепенно станет пережитком... Последний раз редактировалось fed; 20.07.2011 в 17:06. |
|
![]() |
#4 |
Administrator
|
Цитата:
По аналогии, как сейчас при импорте RefRecId пересчитывается. Понятное дело - это не увеличит скорость экспорта / импорта. Зато он будет надежен на 100% (за исключением тех случаев, когда система не сможет догадаться, что для этого поля нужно делать замену. Однако, существующее решение аналогичной проблемы с RefRecId показало - что при желании - можно всего добиться). Занести в бест практис указание использование спец типов для ссылочных полей. И все будут стремиться их использовать.
__________________
Возможно сделать все. Вопрос времени |
|
![]() |
#5 |
Moderator
|
Цитата:
Сообщение от sukhanchik
![]() Ну не согласен. С т.з. хранения ссылок на объекты в данных - конечно да, но я об этом и не говорил. Я говорил про штатную процедуру экспорта / импорта данных. Пусть она немного напряжется и при экспорте - вместо ссылки на объект подставит название объекта, а при импорте - обратно заменит на код.
По аналогии, как сейчас при импорте RefRecId пересчитывается.
|
|