Добрый день! Прошу прощение за отсутствие днем – был занят – до компьютера добрался только вечером.
Итак, отвечаю:
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, так и из диалога, который возникает при создании записи:
Об этом говорил еще 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 – что он может быть перекрыт.
Поля базовой таблицы доступны в производной через this
Цитата:
Сообщение от
S.Kuskov
А тоже самое будет происходить при добавлении таблиц в Query? При создании Query в AOT? При создании Query программно?
Если просто в коде написать "select DirPerson;" будет ли автоматически выбран DirPartyTable?
Из скриншота видно, что будет происходить тоже самое для select.
Для 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 этот тип данных допускает хранение неких списков значений?
Нет. Никаких списков там нет. Я ж говорю - на наследование надо смотреть исходя из гипотезы о том, что это способ вертикального разделения большой мегатаблицы на много маленьких.