Показать сообщение отдельно
Старый 12.01.2012, 23:19   #6  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Добрый день! Прошу прощение за отсутствие днем – был занят – до компьютера добрался только вечером.
Итак, отвечаю:
1. Ссылку от belugin можно расширить на несколько White Paper (http://www.microsoft.com/download/en....aspx?id=20864). Все они лежат в открытом доступе. На самом деле, если ввести в поисковик фразу White Paper AX 2012 можно найти сразу несколько документов по АХ 2012.
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
Ещё прошу подтвердить или опровергнуть следующее высказывание:
Одна и таже запись базовой таблицы может быть связана с записями одновременно из нескольких прозводных таблиц одного уровня иерархии?
2. У главной таблицы может быть несколько подчиненных. Именно для этого и реализовано поле InstanceRelationType типа Int64 в базовой таблице, чтобы можно было по связке [InstanceRelationType, RecId] найти нужную запись в нужной производной таблице. Т.е. код таблицы определяется по полю InstanceRelationType, а RecId как я уже писал выше равны у базовой и производной таблицы. Однако, у одной записи в базовой таблице может быть только одна запись в производной таблице. Это следует как из структуры таблицы и запроса T-SQL, так и из диалога, который возникает при создании записи:
Название: CreateRecord.PNG
Просмотров: 4760

Размер: 17.0 Кб
Об этом говорил еще gigz в своем посте
3. Зачем было сделано равенство RecId между базовой и производной таблицами я не знаю. Но факты – вещь упрямая. Запрос в БД уходит таким, как я показал на скриншотах.
4. Абстрактные таблицы (свойство у таблицы Abstract = Yes). Я о них не стал писать, т.к. в документации сказано так: Any attempt to create a record and insert it in an abstract table will result in a run-time error. (Любые попытки создать запись и вставить ее в абстрактную таблицу приведет к ошибке выполнения). Однако, записи в DirOrganizationBase живут и спокойно себе создаются из формы-примера, который я привел. В чем тогда их абстрактность – я так и не понял.
5. По поводу наследования методов. Дока говорит о том, что «Developers can access the base table method on a derived table buffer. In addition, a derived table method can override a base table method and call super() to invoke the same method on the base table buffer» (Разработчики могут получать доступ к методам на базовой таблице через курсор на производной таблице. В дополнении – метод на производной таблице может перекрыть метод на базовой таблице и вызов super() вызовет метод на базовой таблице).
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
Т.е. через курсор производной таблицы доступны методы базовой.
А можно ли их перекрывать? Доступны ли через курсор производной таблицы поля базовой таблицы?
Смотрим скриншот методов базовой и подчиненной таблице и видим по методу addressBooks – что он может быть перекрыт.
Нажмите на изображение для увеличения
Название: overrideMethods.PNG
Просмотров: 555
Размер:	66.8 Кб
ID:	7464
Поля базовой таблицы доступны в производной через this
Нажмите на изображение для увеличения
Название: overrideFields.PNG
Просмотров: 516
Размер:	30.0 Кб
ID:	7465

Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
А тоже самое будет происходить при добавлении таблиц в Query? При создании Query в AOT? При создании Query программно?
Если просто в коде написать "select DirPerson;" будет ли автоматически выбран DirPartyTable?
Из скриншота видно, что будет происходить тоже самое для select.
Нажмите на изображение для увеличения
Название: selectDirPerson.PNG
Просмотров: 638
Размер:	17.6 Кб
ID:	7466
Для Query после того как в АХ 2009 добавили возможность его добавлять на форму - его поведение можно считать такое же как и у формы. Т.е. также будут выбраны все таблицы из иерархии.
Более того, в обозревателе таблиц теперь показывается все. Т.е. как бы на уровне АХ все таблицы, участвующие в иерархии "склеиваются" в одну. И о том, что таблицы все же разные напоминает лишь АОТ, да СУБД.

Цитата:
Сообщение от TasmanianDevil Посмотреть сообщение
Зачем эти лишние вызовы и ожидания? Только для выполнения странной связи по RecId с обоих сторон join'а ? Как скажется на быстродействии вставки и блокировках на SystemSequences подобный многоступенчатый механизм, гарантирующий выполнение уникальности RecId по таблице и равные RecId у связанных записей в таблицах потомков/родителей ?

Половину этих вызовов ( всех возвратов от базовой записи) можно было бы избежать, используя всего лишь еще одно , дополнительное у к уже имеющемуся полю InstanceRelationType, служебное поле-ссылку (какой-нибудь InstanceRelationRecId) в родительских таблицах на запись в таблице-наследнике.
Тогда вставка в самый нижний уровень не ждала бы вставок с верхнего уровня, а все служебные join можно было реализовать как

Select Родитель Left Outer Join
Потомок On Родитель.InstanceRelationType = Потомок.TableId And Родитель.InstanceRelationRecId = Потомок.RecId
.
Согласен с Вами. Но, возможно, такая концепция не вписывалась в понятие наследования.
С другой стороны - если рассуждать с позиции, что иерархия таблиц - суть есть одна большая таблица - то в общем-то один фиг - что вставлять одну большую запись в мегатаблицу, что вставлять много маленьких записей в иерархию. Если все делать в одной транзакции.
Причем, как я понимаю - условие связи 1:1 (1:0), а не 1:N между базовой и производной таблицами никто не отменял. Возможно, поэтому и возник такой непростой механизм вставки записи.

Цитата:
Сообщение от Владимир Максимов Посмотреть сообщение
Впрочем, не знаю, что это за тип RelationType. Может, в Ax2012 этот тип данных допускает хранение неких списков значений?
Нет. Никаких списков там нет. Я ж говорю - на наследование надо смотреть исходя из гипотезы о том, что это способ вертикального разделения большой мегатаблицы на много маленьких.
__________________
Возможно сделать все. Вопрос времени

Последний раз редактировалось sukhanchik; 12.01.2012 в 23:23.
За это сообщение автора поблагодарили: S.Kuskov (5).