Edit-метод и Relation - баг или фича ?

[TasmanianDevil]

DAX 3.0 SP3

Есть на таблице А edit-метод, редактирующий одно ссылочное поле и возвращающий наименование из ссылочной таблицы B, следующего вида :

edit Name groupName(boolean _set = false, InvestmentAccessGroupCode _id = this.InvestmentAccessGroupCode)
{
    if(_set) this.InvestmentAccessGroupCode = _id;

    return (select GroupName from InvestmentGroupAccess where this.InvestmentAccessGroupCode == InvestmentGroupAccess.GroupCode).GroupName;
}

У таблицы А по этому полю прописан Relation на таблицу B со свойством Validate = Yes.
Есть форма с гридом по таблице А, один из контролов которого завязан на этот edit-метод.

Ситуация : встаем в форме на запись таблицы А с корректным значением ссылки(и результатом edit-метода, естесственно) и, не вызывая lookup, удаляем в контроле , привязанном к edit-методу и доступному для редактирования, часть текста и делаем переход на соседнюю строку.
В оставленной нами строке результат edit-метода - пустой, значение ссылки на таблицу B - кусок текста, являвшегося результатом нашего редактирования и кастрированного до размера EDT ссылочного поля.

Вопрос - где был обозначенный Relation в моменты изменения записи и перехода с нее и что он вообще делал ?

Конечно, подобную ситуацию можно исправить, добавив к проверке на булевский _set еще и проверку на наличие записи в ссылочной таблице через ее метод exist(), однако в таком случае не оставляет смутное ощущение, что меня где-то обманули .

P.S. В 4.0 SP2 FP2 EE аналогично ...

[ZVV]

Это не связано с этими темами никак:
EmplTrans_RU - странный Relations
И снова про Relation

[ZVV]

Да, действительно, проблема не со связями, а с тем что при вызове edit-метода не вызывается метод validateField(), который собственно и делает проверку на связную таблицу.
Остаётся, видимо, только вызвать его вручную в этом методе или допилить validateWrite().

[TasmanianDevil]

Цитата:

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

Это не связано с этими темами никак:
И снова про Relation

Вот эта тема, а точнее упоминание gloomie о срабатывании validateField() после изменения значения поля на форме, подвигла на продолжение эксперимента.
На моей форме изначально не было контрола, ассоциированного с изменяемым полем - добавил для чистоты эксперимента и поставил breakpoint'ы на его modified(), validate() и validateField() на таблицу.
Использовал 4 варианта по два раза - с включенными и отключенными breakpoint'ами для отлова вызова :

1) Изменение поля через прямой lookup()
2) Изменение поля прямым ручным вводом в него
3) Изменение поля косвенно через edit-методом
4) Изменение поля косвенно через ручной ввод в поле с edit-методом

Поле менялось всегда - как в самой таблице, так и в контроле во всех случаях, однако только в первых двух случаях срабатывал breakpoint в validateField() на таблице и выдавал следующий стек

[c] \Data Dictionary\Tables\MyTable\Methods\validateField
[c] \Classes\FormDataObject\validate
[c] \Forms\MyForm\Data Sources\MyTable\Fields\MyField\Methods\validate
[c] \Classes\FormStringControl\Modified

В 3 и 4 случаях не срабатывал ни один из breakpoint'ов ...

Т.е. изменение поля внешним прямым воздействием через форму (lookup, ручной ввод) инициирует выполнение у контрола с этим полем метода modified() и дальнейшую цепочку вызовов до validateField() . Но внутреннее изменение значения контрола через изменение его поля в табличной переменной (edit-методом, ручным вводом в поле edit-метода) - не вызывает у контрола с модифицируемым полем modified() и не порождает цепочки вызовов до validateField().

IMHO, баг ...

[Dron AKA andy]

А почему, собственно, должен вызываться validateField() или modified() для поля таблицы при использовании edit-метода? Мы ж в этом методе программно присваиваем полю значение, а при этом никакие валидейты сроду не срабатывали, хоть черта лысого туда пиши.

[kashperuk]

как раз собрался писать точно то же, что уже написал Dron AKA andy - при чем здесь validateField() к программному изменению значения поля?

[TasmanianDevil]

kashperuk, Dron AKA andy, Вы, видимо , невнимательно прочитали мое сообщение. В первоначальном варианте - изменяемого поля в гриде(и ассоциированного с ним контрола,соотвественно) не было - и тут Вы оба на 100 % правы. Но затем-то это поле было добавлено в грид (см. вложение)! При его программном изменении в процессе исполнения edit-метода на табличной переменной, в гриде значение контрола , ассоциированного с изменяемым полем, тоже изменялось - но к этому-то контролу никто не обращался из кода, к тому же с поля , ассоциированного с edit-методом, перехода не было, фокус выделения никуда не уходил. Вопрос же стоял почему в случае пользовательского изменения содержимого контрола вызывается, а в случае изменения значения у контрола, ассоциированного с изменяемым в коде полем, выполняемого системой, не вызывается modified() у этого контрола ?

В любом случае, именно это вопрос(должен вызываться или не должен вызываться modified() при изменении ядром системы значения контрола) не столь принципиален - по большому счету пофиг как ядро разруливает внутри себя обработку WM_SETTEXT по окну данного контрола, вполне возможно, что сделано сие для предотвращения каких-то подводных камней(типа рекурсий вызовов этих методов при кривом программинге).

Принципиально то, что проверка валидности Relation'ов активируется в исключительно по результатам манипуляций в ассоциированных с полями таблиц контролах формы, а не по результатам изменения табличной переменной датасорса.
Еще раз, повторяясь - IMHO, это архитектурный баг ...

[AndyD]

Так ссылочная целостность в Аксапте только на уровне пользовательского интерфейса и работает (если не считать использование релейшенов в квери и при удалении записей).

Скажем так, Аксапта не доверяет пользователям, но надеется, что программист все сделает правильно

[TasmanianDevil]

Цитата:

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

Скажем так, Аксапта не доверяет пользователям, но надеется, что программист все сделает правильно

Ну на том и порешим
Будем все edit-методы расширять добавочными проверками перед присвоением переданного значения на ::exist() его в ссылочной таблице.

[ZVV]

Цитата:

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

Ну на том и порешим
Будем все edit-методы расширять добавочными проверками перед присвоением переданного значения на ::exist() его в ссылочной таблице.

лучше уж наверное validateField() вызвать самому, если нужна именно стандартная проверка поля.