AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
DAX
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 19.07.2011, 19:11   #1  
Blog bot is offline
Blog bot
Участник
 
25,644 / 848 (80) +++++++
Регистрация: 28.10.2006
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:
  1. Element IDs (like class ID and table ID) are now 32 bit.
  2. Element IDs are installation specific. The same class will have different IDs on different installations.
When making IDs 32 bit we had to deprecate the TypeId() function. TypeId() took one argument the name of an Base Enum or Extended Data Type. And it returned an integer value, where the upper 16 bits were the ID, and the lower 16 bits denoted if the type was a Base Enum or an Extended Data Type. For example: TypeId(MyEDT) returned 0xC351 000B = (50001 > 16 extendedTypeNum(MyEdt) typeId(myEnum) >> 16 enumNum(MyEnum) typeId2ExtendedTypeId(typeId(myEdt)) extendedTypeNum(MyEdt) As element IDs now are installation specific then we need to provide enough information for data export/import to convert the data correctly between the source and target system. There are 3 things to do:
  1. Do not store IDs in containers,
    If IDs are stored in a non-relational format (like a container), then data export/import cannot identify them, and the IDs will be imported as-is; which means they will resolve incorrectly on the target system. A best practice rule is available to identify IDs in containers.
  2. Use the right Extended Data Types on your fields (TableId, FieldId, ClassId, etc.)
    Data export will convert data using these Extended Data Types into a format that can be correctly resolved on the target system.
  3. For fields containing field IDs
  1. Set the RelatedTable property, OR
  2. Create a new field group with the field referencing the table and the field referencing the field.
For data export/import to be able to correctly convert a field ID, it is required that you specify which table the field belongs to. If the field always belongs to the same table, you can use the RelatedTable property to specify it (3.1), OR if the field ID is referencing a field in an arbitrary table, you need to link the table reference and the field reference to each other. You do this by creating a new field group containing the two fields (3.2) THIS POST IS PROVIDED AS-IS AND CONFERS NO RIGHTS.




==============
Источник: http://blogs.msdn.com/b/mfp/archive/...cific-ids.aspx
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
Старый 19.07.2011, 21:16   #2  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,342 / 3563 (125) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Хм... разные ID у одного и того же объекта будут в разных инсталляциях. Допустим.
У поля будет свойство RelatedTable. Это хорошо, когда ссылки на одну таблицу (типа InventSettlement -> InventTrans, VendTransOpen -> VendTrans).
А когда разные - предлагается создать группу полей. И ЧТО ЭТО ДАСТ?

Дальше. А коды других объектов уже в БД не будут храниться? Ну там типа методов экспорта платежных поручений в способах оплаты.

Мне вот интересно - а насколько сложно сделать элементарную вещь: Пусть в файле экспорта данных вместо ID объектов подставляется реальное название объекта. Вместо вот этих вот 16-ричных цифр - просто название. Все! Это же решит проблему.

Никто не переносит данные между принципиально разными приложениями. Ну или переносит с пониманием того, чего делает. А вот перенос данных между одинаковыми приложениями - легко. Ну и пусть будет идентификация по именам! Только для переноса. А ID-шники в общем-то и сейчас сильно зависят от инсталляции (за исключением конечно стандартного функционала)
__________________
Возможно сделать все. Вопрос времени
Старый 20.07.2011, 16:48   #3  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,913 / 5736 (197) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Ну собственно они по похожей схеме и пошли. В предыдущей статье 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, при таком подходе, постепенно станет пережитком...

Последний раз редактировалось fed; 20.07.2011 в 17:06.
Старый 20.07.2011, 18:37   #4  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,342 / 3563 (125) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от fed Посмотреть сообщение
Именами не стали пользоваться чтобы дать возможность переименовывать объекты при рефакторинге (что полезно).
Ну не согласен. С т.з. хранения ссылок на объекты в данных - конечно да, но я об этом и не говорил. Я говорил про штатную процедуру экспорта / импорта данных. Пусть она немного напряжется и при экспорте - вместо ссылки на объект подставит название объекта, а при импорте - обратно заменит на код.
По аналогии, как сейчас при импорте RefRecId пересчитывается.
Понятное дело - это не увеличит скорость экспорта / импорта. Зато он будет надежен на 100% (за исключением тех случаев, когда система не сможет догадаться, что для этого поля нужно делать замену. Однако, существующее решение аналогичной проблемы с RefRecId показало - что при желании - можно всего добиться).

Занести в бест практис указание использование спец типов для ссылочных полей.
И все будут стремиться их использовать.
__________________
Возможно сделать все. Вопрос времени
Старый 21.07.2011, 09:47   #5  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,913 / 5736 (197) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Ну не согласен. С т.з. хранения ссылок на объекты в данных - конечно да, но я об этом и не говорил. Я говорил про штатную процедуру экспорта / импорта данных. Пусть она немного напряжется и при экспорте - вместо ссылки на объект подставит название объекта, а при импорте - обратно заменит на код.
По аналогии, как сейчас при импорте RefRecId пересчитывается.
Рискну предположить что:
  • Имя, в среднем, длиннее GUID
  • Имя может поменяться между версиями из за рефакторинга
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
mfp: The solution to the element ID problem Blog bot DAX Blogs 0 12.07.2011 19:12
mfp: Adapting to installation specific IDs Blog bot DAX Blogs 0 03.01.2011 20:12
semanticax: Dynamics AX 2009 Installation - Application Blog bot DAX Blogs 0 22.12.2010 08:11
CRM DE LA CREME! CRM Installation Tips Blog bot Dynamics CRM: Blogs 0 21.05.2010 10:05
mfp: AX6 sneak preview - elements with 32 bit IDs Blog bot DAX Blogs 10 30.05.2009 10:45

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 06:39.