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

[moid]

Как такую конструкцию:

//...
      //  SPLJLH = qr.get(tablenum(SalesPickingListJournalLineHistory));
        while select sum(SalesQty) from SPLJLH
        group by ModifDate
        where SPLJLH.EmplId == it.value()
//...

записать в Range?

[Delfins]

Так это стандартный Range:

range = sysquery::findorcreaterange(...);
range.value(it.value());

[belugin]

     Query q=new Query();   
     //while select sum(SalesQty) from SPLJLH
     QueryBuildDataSource ds = q.addDataSource(tableNum(SPLJLH));
;
        //group by ModifDate
     ds.OrderMode(OrderMode::GroupBy);
     ds.addSortField(fieldNum(SPLJLH, ModifDate));
     ds.addSelectionField(fieldNum(SPLJLH, SalesQty), SelectionField::Sum);
        //where SPLJLH.EmplId == it.value()
     ds.addRange(fieldNum(SPLJLH, EmplID)).value(queryValue(it.value()));

[mazzy]

Цитата:

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

     Query q=new Query();   
     //while select sum(SalesQty) from SPLJLH
     QueryBuildDataSource ds = q.addDataSource(tableNum(SPLJLH));
;
        //group by ModifDate
     ds.OrderMode(OrderMode::GroupBy);
     ds.addSortField(fieldNum(SPLJLH, ModifDate));
     ds.addSelectionField(fieldNum(SPLJLH, SalesQty), SelectionField::Sum);
        //where SPLJLH.EmplId == it.value()
     ds.addRange(fieldNum(SPLJLH, EmplID)).value(queryValue(it.value()));

Категорически против такого варианта - нахлебался в русской функциональности.
Он правилен, но чертовски трудномодифицируемый и трудноапгрейдируемый.

Создайте Query в AOT с датасорсом, группировками и прочими параметрами. Можно мышкой и drag'n'drop'ом
В коде напишите две строчки как написал Delfins.

Query q=new Query(querystr(mySuperEmplQuery));  

// 2 строчки от Delfins
range = sysquery::findorcreaterange(q,...);
range.value(it.value());

Можете написать в одну строчку, если отлаживать не надо

sysquery::findorcreaterange(new Query(querystr(mySuperEmplQuery)),...).value(it.value());
//

Но только не надо генерить кучу кода, пожалуйста.

Max, давай советовать минимальное программирование?

PS Кроме того, подход с созданием Query в AOT позволяет разделить задачу оптимизации производительности между кодером и администратором. Администратор может исправить Query не затрагивая кода.

[belugin]

Цитата:

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

Кроме того, подход с созданием Query в AOT позволяет разделить задачу оптимизации производительности между кодером и администратором. Администратор может исправить Query не затрагивая кода.

Интересно, пробовал ли кто-нибудь такой подход как основной - нет ли каких-нибудь подводных камней при массовом использованиии?

[mazzy]

Цитата:

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

Интересно, пробовал ли кто-нибудь такой подход как основной - нет ли каких-нибудь подводных камней при массовом использованиии?

Да, есть один большой подводный камень - русская функциональность.
Запросы в русской функциональности кодируются таким хитровывернутым способом, что просто слов нет.

[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()

[moid]

Сделал как написал belugin все работает. Спасибо....

[Tiruvileijadal']

Цитата:

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

Категорически против такого варианта - нахлебался в русской функциональности.
Он правилен, но чертовски трудномодифицируемый и трудноапгрейдируемый.

Создайте Query в AOT с датасорсом, группировками и прочими параметрами. Можно мышкой и drag'n'drop'ом
В коде напишите две строчки как написал Delfins.

Query q=new Query(querystr(mySuperEmplQuery));  
 
// 2 строчки от Delfins
range = sysquery::findorcreaterange(q,...);
range.value(it.value());

А в каком методе писать эти строчки, если класс - наследник от RunBaseBatch?

[kashperuk]

если от RunBaseReport, то можно в initQuery(), к примеру

а вообще - см.метод queryRun() - он содержит выполнимый запрос. Его можете менять.
Поставьте бряк, посмотрите, откуда он вызывается, и вставьте добавление фильтров перед этим.