Вопрос о корректности Relations

[Gustav]

Уважаемые коллеги, обнаружил у себя в репозитарии следующую ситуацию:

В таблице RAssetTable в узле Relations отношение OrgAddressTable состоит из двух линий (обе линии с типом TableRelation::Field):

1. OrgAddrAc
2. RAssetTable.OrgId == OrgAddressTable.OrgId

Сдается мне, что с линией 1 не всё в порядке... А у вас как выглядит этот Relation?

[_AnK_]

У меня такого релейшена вообще нет. Это у вас кастомизация такая =)

[Gustav]

Цитата:

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

У меня такого релейшена вообще нет. Это у вас кастомизация такая =)

Ну похоже на то. Причем компиляция таблицы не ругается никак. А чего с ним делать-то: убить или забить?

[_AnK_]

1. Разобраться что за таблица OrgAddressTable (тоже кастомизация), нафига этот релейшен, и каким он должен быть на самом деле.
2. Вздрючить афтара косяка.

=)

[Gustav]

Цитата:

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

2. Вздрючить афтара косяка.

Увы, это не так просто. Как у Райкина: "Кто шил костюм? - Выходят 100 человек."
Меня смущает другое: если можно ввести кривой релейшн, то как на него система реагирует в дальнейшем? Просто игнорирует?

P.S. Relations вообще несут какую-нибудь нагрузку в плане контроля целостности и т.п.? Или это не более чем информация о, скажем так, "рекомендуемо-предполагаемой" связи таблиц, которую в принципе можно нарушить вводом в связанные таблицы данных, которые не будут соответствовать этой связи?

P.S.2. И еще вопрос. Конкретный Relation по определению относится к двум таблицам. В репозитарии же конкретный Relation указывается только на одной таблице из двух. Вопрос - на какой? На той, которая на стороне "многие" в отношениии "1:многие"? Или действует какой-то другой принцип?

[sukhanchik]

Цитата:

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

Меня смущает другое: если можно ввести кривой релейшн, то как на него система реагирует в дальнейшем? Просто игнорирует?

По сути - релейшны нужны для организации лукапов и переходов к основной таблице - по умолчанию, без каких либо перекрытий в форме. Ну и заодно - служат проверкой при сохранении записи (чтобы выбирали только значения из лукапа).
Т.е. по приоритетам, в порядке убывания строится так:
1. (самый важный) - перекрытый метод lookup/jumpref
2. (если методы не перекрыты) - согласно информации о релейшнах на таблицах
3. (если информация на таблицах отсутствует) - согласно информации о релейшнах на расширенном типе данных.
Если будет кривой релейшн то система может отреагировать двояко:
1) Если сумеет разобраться - то построит лукап и переход к основной таблице и будет делать проверку введенного значения. (Вопрос - будет ли полученный результат совпадать с желаемым)
2) Если не сумеет разобраться (или же как здесь - поле возможно было удалено) - то просто проигнорирует релейшн (будет искать правильный релейшн на расширенном типе данных)

Цитата:

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

P.S. Relations вообще несут какую-нибудь нагрузку в плане контроля целостности и т.п.? Или это не более чем информация о, скажем так, "рекомендуемо-предполагаемой" связи таблиц, которую в принципе можно нарушить вводом в связанные таблицы данных, которые не будут соответствовать этой связи?

Не-а. Не несут. Информация может использоваться в перекрестных ссылках, при построении запроса (querybuilddatasource.relations(true)); при построении пользовательского запроса (по Ctrl+F3) - при добавлении таблицы или еще в подобных ситуациях.

Цитата:

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

P.S.2. И еще вопрос. Конкретный Relation по определению относится к двум таблицам. В репозитарии же конкретный Relation указывается только на одной таблице из двух. Вопрос - на какой? На той, которая на стороне "многие" в отношениии "1:многие"? Или действует какой-то другой принцип?

Да, там где многие. См табл custTrans и rcontractTable

[Gustav]

2 sukhanchik: Спасибо за развернутый ответ и поздравления с юбилейным 300-м сообщением

[sukhanchik]

Спасибо за поздравления! Есть повод отметить

[Владимир Максимов]

Вообще-то, есть место, где Relation работает в смысле организации целостности данных. Это узел DeleteAction на таблице.

Здесь, по умочанию, используются ВСЕ relation, так или иначе организованные между двумя таблицами. Как через EDT, так и через узел Relation

[sukhanchik]

Хм... вот про него-то я и забыл... спасибо за ценное замечание.