EmplTrans_RU - странный Relations

[Deep Dreamer]

Может я совсем туплю, но что это:

[mit]

А это? может тоже самое?

[Deep Dreamer]

А смысл?

[mit]

нет, ответил не в тему сразу не заметил что это RecId. действительно непонятно. возможно, ошибка.

[Modus]

Ладно бы там был EDT, от которого они поленились что-то унаследовать и перекрыли отношение на таблице...

[kashperuk]

Relation по ItemId на саму таблицу есть в InventSum тоже.

InventSum.ItemId = InventSum.itemId

Так зачем?

[George Nordic]

Не вижу, что Вы такого странного в это ситуации. Что запрещает джойнить таблицу саму к себе? Вот для этого и сделан этот рилэйшн.

С Уважением,
Георгий

[Modus]

И что это даст, если у нас одно и то же поле? Типа если это значение встречается несколько раз, то в таблице к ней прицепятся аналогичные? А почему она не может приджойниться так, что совпадет сама с собой?

[EVGL]

Не в первый раз поднимался этот вопрос. Эта relation сделана для того, чтобы Best Practices не ругался. Вот и все. А Best Practices ругается тогда, когда переименование первичного ключа невозможно, т.е. нет уникального индекса. Поэксперементируйте, и все станет понятно.

[Dron AKA andy]

Насколько я понимаю, эти релэйшны позволяют системе понять, как связать формы при открытии одной формы из другой через menuitem.
Поясняющий пример: если бросить на форму InventSum menuitem, запускающий саму эту форму InventSum, то при наличии вышеприведенного релэйшна при нажатии созданной кнопки записи в открывшейся форме будут отфильтрованы по текущему ItemId, и эта связь будет сохраняться при перемещении по записям первой формы (dynalink).

[AndyD]

Цитата:

А Best Practices ругается тогда, когда переименование первичного ключа невозможно, т.е. нет уникального индекса

А как может быть первичный ключ неуникальным?

[EVGL]

Цитата:

А как может быть первичный ключ неуникальным?

Не понял вопроса. Речь не о том.

Функция такая есть в Аксапте - переименовать первичный ключ. Обычно ссылка на самого себя стоит в EDT. Используется в переименовании из контекстного меню. Раньше Best Practices были слегка параноидальными и ругались на отсутствие ссылки на самого себя.

[Logger]

Цитата:

Сообщение от EVGL

Раньше Best Practices были слегка параноидальными и ругались на отсутствие ссылки на самого себя.

Думаю что не только по этой причине делают в Relation связь таблицы самой на себя.

Тут все хитрее. Дело в том что движок Аксапты может определять связь между таблицами как через связи определенные на EDT, так и через связи определенные на уровне таблиц, причем у последних приоритет выше.

У меня был реальный пример. Есть таблица SalesTable - у неё не определена связь на саму себя через salesId. Если на форме SalesTable нажать Запросы - Итоги - то откроется форма подсчета итогов и сработает Dynalink - будет связь по SalesId. Спрашивается, откуда она взялась ? Судя по всему из расширенного типа данных которые прописан в SalesTable.salesId

Далее, делаем какую-нить кастомизацию - определяем на SalesTable составной relation по 3 новым полям.
SalesTable.CUSTOM_DataAreaId == SalesTable.DataAreaID
SalesTable.CUSTOM_SalesId == SalesTable.SalesId
SalesTable.CUSTOM_SourceType == 0 // поле с типом Енум - неважно какое.
(Это мы цепочки писали - задавали таким образом свои связи между заказами в разных компаниях)

И после этого ломается форма Запросы - Итоги !!! Везде.
Даже на тех заказах, на которых поля
SalesTable.CUSTOM_DataAreaId
SalesTable.CUSTOM_SalesId
SalesTable.CUSTOM_SourceType
пустые !

Оказывается система подхватывал Dynalink уже по новой связке ! Хотя по идее не должна была. Так как значения в полях не подходили. Она взяла кусок Relation-а и стала по нему делать Dynalink !

Т.е. получается что ядро Аксапты видит, что в relation-х таблицы есть связка по SalesId - после этого забивает на связки в расширенных типах которые прописаны в полях. Выкусывает из составного relation по 3-м полям связку по одному полю SalesId.CUSTOM_SalesId == SalesTable.SalesId и использует его в качестве Dynalink при вызове Запросы - Итоги

Пипец.
Но стоило мне определить на таблице отдельный Relation с тавтологической связкой
SalesTable.SalesId == SalesTable.SalesId
как все чудесным образом вылечилось.

[EVGL]

Цитата:

Сообщение от Logger

Тут все хитрее. Дело в том что движок Аксапты может определять связь между таблицами как через связи определенные на EDT, так и через связи определенные на уровне таблиц, причем у последних приоритет выше.

Вы ошибаетесь. Приоритет связей на уровне расширенного типа на самом деле ВЫШЕ, чем у таблицы, и это полное гадство. Именно поэтому в системе полно расширенных типов вроде XXXBaseXXXid, не имеющих связей. Другими словами, если на типе есть связь, то она имеет наивысший приоритет. Если связи на типе нет, то берется связь из таблицы.

[kashperuk]

Цитата:

Сообщение от EVGL

Вы ошибаетесь. Приоритет связей на уровне расширенного типа на самом деле ВЫШЕ, чем у таблицы, и это полное гадство. Именно поэтому в системе полно расширенных типов вроде XXXBaseXXXid, не имеющих связей. Другими словами, если на типе есть связь, то она имеет наивысший приоритет. Если связи на типе нет, то берется связь из таблицы.

На самом деле - странное утверждение, учитывая, что это довольно просто проверить.

Создаем таблицу с 1 полем, тип поля - ItemId.
Создаем на таблице Relation по этому полю на таблицу SalesLine (по ItemId)

Открываем браузер таблиц, создаем запись и открываем лукап - видим записи из SalesLine. Соответственно, relation по таблице имеет приоритет выше, чем relation по EDT

Или я не понял смысла дискуссии?

[Zeppelin]

Чтобы не создавать новой ветки

Цитата:

Сообщение от kashperuk

На самом деле - странное утверждение, учитывая, что это довольно просто проверить.

Создаем таблицу с 1 полем, тип поля - ItemId.
Создаем на таблице Relation по этому полю на таблицу SalesLine (по ItemId)

Открываем браузер таблиц, создаем запись и открываем лукап - видим записи из SalesLine. Соответственно, relation по таблице имеет приоритет выше, чем relation по EDT

Или я не понял смысла дискуссии?

А если модифицировать пример Ивана , предположим так

Создаем таблицу с 2 мя полями
1 ItemID тип поля - ItemId.
2 SalesId тип поля - SalesIdBase
Создаём Relation по этим двум полям на таблицу SalesLine
MyTable.ItemId == SalesLine.ItemId
MyTable.SalesId == SalesLine.SalesId


То при этом переход к основной таблице кардинально изменится - будет происходить на основании EDT к InventTable , а не к SalesLine (причём пара значений ItemId,SalesId присутствует в SalesLine) Вопрос - почему так происходит, если судя по вышеизложенному переход должен осуществляться
на основании Relation т е к SalesLine

Спасибо !

[AndyD]

Понял. Спасибо.

[sukhanchik]

2Logger:
У Аксапты есть еще одна фича. Если на таблице определено 2 взаимоисключающих релейшна, по которым она строит dynalink-и, лукапы, переходы к основной таблице - то она берет 1-й по алфавиту по названию релейшна.
Т.е. в Вашем случае - Вы скорее всего сделали новый релейшн, который по алфавиту стал раньше стандартного. Если у вас есть возможность проверить - переименуйте Ваш релейшн так, чтобы он по алфавиту стал позже стандартного. Скорее всего у вас будет тот же эффект, что и при удалении релейшна.

Так что, я больше склоняюсь к мысли о Best Practice.

[Logger]

Цитата:

Сообщение от sukhanchik

2Logger:
Т.е. в Вашем случае - Вы скорее всего сделали новый релейшн, который по алфавиту стал раньше стандартного.

Да не было там стандартного
В SalesTable нет стандартных Relation содержащих связку по SalesId
Так что тут другой случай.

[Logger]

Перепроверил пример, действительно, все дело было в том какой Relaton раньше стоит в АОТ. Значит система не делает никаких извращений с Relation и по частям их не использует.

sukhanchik - респект.

Что же теперь получается - если хотим своими модификациями по минимуму влиять на стандартное поведение системы, то Relation-ы надо называть так чтобы они в конце списка были? Типа префикс "ZZZ_" использовать?