Цитата:
Сообщение от
Delfins
На то он и Query в AOT, что бы юзался многократно... а если надо специфический, то тогда создавайте подобный используя метод "Duplicate"
Конечно, если меняется логика Q, то тогда об этом должны знать все кодеры... Это уже другая тема.
Query в AOT может использоваться и однократно.
Все равно выигрыш будет за счет более понятной логики, меньших затрат при оптимизации запроса и более легкого апгрейда.
Администратор не должен менять логику при оптимизации запроса.
Цитата:
Сообщение от
mazzy
Да, есть один большой подводный камень - русская функциональность.
Стереть, что ли этот оффтопик?
Чтобы вернуться к теме
Цитата:
Сообщение от
belugin
Интересно, пробовал ли кто-нибудь такой подход как основной - нет ли каких-нибудь подводных камней при массовом использованиии?
Да, есть подводный камень.
Если в высоком слое был добавлен датасорс, то в низком слое его не удалишь даже если он больше не нужен. В основном это касается взаимодействия var/cus/usr, но и в системных такое тоже бывает. Например, запрос InventSumCount зачем-то содержит join к InventTable, хотя в коде эта таблица из запроса не используется. В результате для оптимизации приходится делать дубль и править класс inventCountCreate.initQueryRun()
Но даже в этом случае изменение имени запроса выполняется гораздо легче, нежели изменение кучи кода по программному созданию запроса.
Сравните:
BookDataCalc_Purch_Process_RU.initOnDelivery()
BookDataCalc_Purch_Process_RU.initParmDefault()
BookDataCalc_Purch_Process_RU.initTransitionPeriod()
BookDataCalc_Purch_Process_RU.inRangeIntoQueryRun()
BookDataCalc_Purch_Process_RU.qrSettlementDependent()
BookDataCalc_Purch_Process_RU.qrSettlementInDependent()