Показать сообщение отдельно
Старый 11.01.2017, 11:12   #15  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от 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, ужаснулись - и сделали перебор полей по-старинке
За это сообщение автора поблагодарили: mazzy (2), Logger (3), ax_mct (4).