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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 22.05.2008, 03:09   #1  
Blog bot is offline
Blog bot
Участник
 
25,631 / 848 (80) +++++++
Регистрация: 28.10.2006
mfp: Solving the element ID problem
Источник: http://blogs.msdn.com/mfp/archive/20...d-problem.aspx
==============
We've had feedback from many sources (comments in this blog, emails, in-person meetings, partner advisory board, etc.) that we should fix the element ID problem in AX - the sooner the better. Thank you very much for this feedback. This post is intended to give a bit of background on this subject.
The element ID problem in AX causes pain on two fronts:
  1. Uniqueness. Element IDs must be unique on any given installation. We have a suite of tools to help generating unique IDs, detect uniqueness conflicts, etc. Learning and using these tools are painful, resolving ID problems is even more painful, especially on live systems. Further the uniqueness issue makes it hard to combine solutions from different source in one installation.
  2. Upper limit. Each layer has a finite number of IDs. This means there is an upper limit to how many model elements you can create. Microsoft's core development team knows exactly how this pain feels.
At any rate; this is a problem we need to address - and my team has been given the task. While many solutions spring to mind (use GUIDs or drop IDs completely) this is a case of Devil in the Details.

Business Data: IDs are persisted in the business data base. Any change to IDs would require upgrade scripts. To make matters even worse, IDs are also stored in unstructured blobs; making identification and migration even harder.
Business Logic: Business logic uses IDs. Both Microsoft's business logic; but certainly also the business logic in solutions authored by partners around the world. Changes to IDs would impact all this business logic.

Kernel: The implementation of the kernel used IDs heavily. Changing data type or dropping IDs totally would require rewrite of large portions of the kernel.The kernel provides the API for converting IDs to names and back again.
Application model: IDs (and Names) are stored in the Application Model. IDs are used as references between model elements and IDs bind customizations to the original element. Whatever changes we make, we cannot break the references in the model.


Getting challenges like this is what I love about my job.




==============
Источник: http://blogs.msdn.com/mfp/archive/20...d-problem.aspx
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
DynaMihamAX: Label import problem in Dynamics AX 4.0 Blog bot DAX Blogs 0 12.12.2008 13:05
mfp: Summer is over... Blog bot DAX Blogs 0 05.09.2008 21:05
mfp: Late night discussion on software development #2: Estimation Blog bot DAX Blogs 0 18.01.2008 16:30
mfp: Articles on X++ development Blog bot DAX Blogs 0 23.08.2007 23:40
mfp: Sneak preview - Code Upgrade Enhancements Blog bot DAX Blogs 0 02.03.2007 20:46
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

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

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