Как такую конструкцию записать в Range?

[Delfins]

На то он и Query в AOT, что бы юзался многократно... а если надо специфический, то тогда создавайте подобный используя метод "Duplicate"

Конечно, если меняется логика Q, то тогда об этом должны знать все кодеры... Это уже другая тема.

[mazzy]

Цитата:

Сообщение от 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()