Цитата:
Сообщение от
mazzy
а как сейчас работает логика defaulting'а? сейчас это просто значение, отличное от записанного в базу? или как-то по-другому?
Насколько я знаю, точно так же, как и раньше, поддерживается набор флажков для полей, показывающих, устанавливалось ли значение поля (любое, даже "пустое", типа 0 или dateNull()) после clear/select/update или еще не устанавливалось. Не важно значение поля, важен факт того, было ли оно явно установлено. Хотя, конечно, с точки зрения экономии на объеме передаваемых данных следовало как раз-таки сравнивать значение поля с "пустым" значением для данного базового типа, и если они совпадают, то не сериализовывать такое значение - зачем передавать, что называется, детерминированный сигнал?..
Цитата:
Сообщение от
ax_mct
как думаю initValue() делает defaulting.
По-моему, тут о разных понятиях речь. В моем понимании задача логики defaulting'а - неявно подтягивать значения по умолчанию либо значения связанных полей
на основе тех полей, которые заданы явно. Например, проставили в шапку заказа на продажу код клиента - defaulting должен подтянуть из клиента фин.аналитики, адрес доставки, способ оплаты, налоговую группу, etc. Особенность работы defaulting'а была и есть в том, что он не должен перезаписывать явно заданные "извне" значения, скажем, если мы вместе с кодом клиента явно прописали адрес доставки не по умолчанию, до defaulting не должен его перезаписывать "своим" значением. Именно для отслеживания того, какие поля были заданы, а какие нет, и использовался прежде метод isFieldSet(). В том числе он использовался для того, чтобы в defaulting'е одного поля понять, было ли задано явно или "по умолчанию" другое поле.
Цитата:
Сообщение от
dech
Очевидно, что после любого присваивания, даже дефолтного метод вернет true. False, если поле вообще не трогали.
Очень хорошее замечание - в исходном классе AxInternalBase метод isFieldSet() анализировал множество идентификаторов под названием fieldTouched
Также там был метод setFieldAsTouched(), вызывавшийся из setField(), который, в свою очередь, использовался для установки значений полей. В 2012-й всю эту логику запихали в ядро, насколько я понимаю. В общем, действительно, дело в том, трогали ли поле
Цитата:
Сообщение от
mazzy
ну... там вообще нужно было бы использовать SysDictTable.fields() и енумератор. но не будем придираться к оформлению. со стороны ритейл-модулей много кода от людей, которые похоже плохо знают аксапту )
Возможно, люди, писавшие ритейл-модуль, просто гоняли тесты производительности перед выпуском, посмотрели в каком-нить профайлере, сколько новых объектов в памяти генерит вызов SysDictTable.fields(), сопоставили это с особенностью работы сборщика мусора в CIL, ужаснулись - и сделали перебор полей по-старинке
