вопрос по Query

[propeller]

Простейшая задача: есть query по таблице CustTable с какими-то условиями.
Есть значение "КлиентАБВ".

Нужно проверить, есть ли запись с таким значением поля AccountNum в имеющемся query.
Понято, через queryRun.next() можно перебрать все записи и условием проверить, но хотелось бы по быстрей и покрасивей.

[Jorj]

А что если создать копию этого query и добавить туда ренж по AccountNum, много перебирать не надо, поле уникальное – достаточно одного одного queryRun.next().

[S.Kuskov]

В общем случае подцепить к имеющемуся query ещё один CustTable с типом связи exists join и наложить уже на него условие "КлиентАБВ". Затем, сделав один раз queryRun.next(), посмотреть вернулось ли что-нибудь.

to Jorj: если в исходном query на поле AccountNum уже есть условие, то ещё одно условие "КлиентАБВ". добавится к нему через "ИЛИ".

Ещё вариант, чтобы добится присоединения условия через "И",можно воспользоваться "расширенным синтаксисом" range (http://www.axaptapedia.com/Expressions_in_query_ranges) и добавить условие "КлиентАБВ" через какое-нибудь свободное поле (например через recid. Но и тогда в общем случае могут возникнуть проблемы совместимости, например при наличии RLS: Что делает RLS с связанными запросами в отчете).

[Владимир Максимов]

Цитата:

Сообщение от S.Kuskov

В общем случае подцепить к имеющемуся query ещё один CustTable с типом связи exists join и наложить уже на него условие "КлиентАБВ". Затем сделав один раз queryRun.next() посмотреть вернулось ли что-нибудь.

К сожалению, это ничего не гарантирует. Если исходный запрос относительно сложен и имеет несколько таблиц-источников с "не линейной" схемой объединения, то подключение еще одного источника по Exists Join может привести к тому, что запросу "снесет крышу". Результат может оказаться парадоксальным.

В принципе, общая идея, заключающаяся в том, что нужно наложить еще один Range по этому полю - правильная. Проблема только в том, что этот Range должен подкючаться по "И", а если уже есть Range по этому же полю, скажем, настроенный пользователем, то подключение произойдет по "ИЛИ"

Именно для данного конкретного случая можно сделать "хитрый трюк". Дело в том, что определение того факта, что Range добавляется по уже существующему полю выполняется по Id поля. При этом, как правило, используется FieldId. Однако Axapta может идентифицировать поле как по FieldId, так и по ExtendedFieldId. Т.е. идентифицировать поле, как первый элемент массива.

Естесственно, что FieldId и ExtendedFieldId - это разные значения. Как следствие, построитель запросов интепретирует их как разные Range и выполняет объединение по "И".

Получается, примерно следующее

static void Job_Test(QueryRun   queryRun)
{
    Query                   queryFind;
    QueryRun                queryRunFind;
    QueryBuildDataSource    qbds;
    QueryBuildRange         qbr;
    ;
    
    queryFind = new Query(queryRun.query().pack());
    qbds = queryFind.dataSourceTable(tablenum(CustTable));
    
    // Вот этот трюк
    qbr = qbds.findRange(fieldnum(CustTable, accountNum));
    if (qbr)
    {
        // Если Range уже есть, то создаю новый Range по ExdendendFieldId
        qbr = qbds.addRange(fieldId2ext(fieldnum(CustTable, accountNum),1));
    }
    qbr.value('КлиентАБВ');
    
    
    queryRunFind = new QueryRun(queryFind);
    if (queryRunFind.next())
    {
        info("Есть такая запись");
    }
    
}

Естесственно, этот трюк работает только для полей, которые массивами не являются. Для полей-массивов можно сделать подобное только для первого элемента массива.

[S.Kuskov]

Цитата:

Сообщение от Владимир Максимов

Именно для данного конкретного случая можно сделать "хитрый трюк".

Да про данный "трюк" я в курсе. Но сдаётся мне что это поведение запросто могут "исправить" в какой-нибудь следующей версии системы.

Если выбирать из предложенных вариантов, то мне больше нравится мой про использование http://www.axaptapedia.com/Expressions_in_query_ranges

P.S.: propeller, вот уж действительно "простейшая задача"

[dn]

Цитата:

Сообщение от S.Kuskov

В общем случае подцепить к имеющемуся query ещё один CustTable с типом связи exists join и наложить уже на него условие "КлиентАБВ". Затем, сделав один раз queryRun.next(), посмотреть вернулось ли что-нибудь.

Цитата:

Сообщение от Владимир Максимов

К сожалению, это ничего не гарантирует. Если исходный запрос относительно сложен и имеет несколько таблиц-источников с "не линейной" схемой объединения, то подключение еще одного источника по Exists Join может привести к тому, что запросу "снесет крышу". Результат может оказаться парадоксальным.

А если использовать не ExistsJoin, а InnerJoin?

boolean findSuperCust(Query _srcQuery, CustAccount _custAccount = "КлиентАБВ")
{
    Query                   q;
    QueryRun                qr;
    QueryBuildDataSource    qbds,qbds2;
    ;
    q               = new Query(_srcQuery);
    qbds            = q.dataSourceTable(tablenum(custTable));
    qbds2           = qbds.addDataSource(tablenum(custTable));
    qbds2.fields().addField(fieldNum(custTable, AccountNum));
    qbds2.fetchMode(JoinMode::INNERJOIN);
    qbds2.relations(true);
    qbds2.addRange(fieldNum(custTable, AccountNum)).value(_custAccount);    
    qr = new QueryRun(q);
    return qr.next();  
}

[AndyD]

Цитата:

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

    qbds2.fetchMode(JoinMode::INNERJOIN);

Вы, наверное, с JoinMode() перепутали?
Но FetchMode() тоже надо будет настраивать, если есть другие датасорсы, подключенные к CustTable.

А основная проблема с этим запросом - не может Аксапта обрабатывать большое количество вложенных подзапросов. Особенно, если они находятся на одном уровне вложенности

[dn]

Цитата:

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

Вы, наверное, с JoinMode() перепутали?
Но FetchMode() тоже надо будет настраивать, если есть другие датасорсы, подключенные к CustTable.

Спасибо, за поправку.
qbds2.joinMode(JoinMode::innerJoin);
qbds2.fetchMode(QueryFetchMode::One2One);

Цитата:

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

А основная проблема с этим запросом - не может Аксапта обрабатывать большое количество вложенных подзапросов. Особенно, если они находятся на одном уровне вложенности

Возможно. Но на практике, когда не проходил ExistJoin, вариант с InnerJoin проходил. Хотя согласен, что в общем случае это видимо не всегда будет работать.

[mazzy]

Цитата:

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

А основная проблема с этим запросом - не может Аксапта обрабатывать большое количество вложенных подзапросов. Особенно, если они находятся на одном уровне вложенности

может-может.
только в случае нескольких вложенных таблиц Аксапта возвращает записи ПОСЛЕДОВАТЕЛЬНО.

я уже ссылку давал

Цитата:

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

вариант S.Kuskov: приджойнить exist join тоже не подойдет. поскольку в запросе уже может быть join. http://msdn.microsoft.com/en-us/libr...36(AX.10).aspx

прикладываю и картинку

[S.Kuskov]

Цитата:

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

Но FetchMode() тоже надо будет настраивать, если есть другие датасорсы, подключенные к CustTable.

Про FetchMode хорошо написал Иван Кашперук Связывание источников данных в запросах

Цитата:

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

А основная проблема с этим запросом - не может Аксапта обрабатывать большое количество вложенных подзапросов. Особенно, если они находятся на одном уровне вложенности

Соглашусь с тем что замена "exists join" на "inner join" во многих случаях поможет, но не всегда.
Проблема с "exists join" связана с тем, что если такой exists будет вставлен между двумя таблицами уже соеденёнными при помощи "inner join", то результирующий запрос получится не всегда ожиданным.

Например, такой гипотетический код:

select Table1
exists join Table3 where Table3.id == Table1.id
inner join Table2 where Table2.id == Table1.id

будет преобразован примерно вот в такой запрос:

table1 where exists (select Table3 join table2)

Если обойтись без Exists join и всегда использовать Inner join, то тогда проблема может появится уже по другой причине. Может быть превышено максимальное число приджойненных таблиц.

[S.Kuskov]

Цитата:

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

или не содержал И искомого значения в базе вообще нет.

Ну это легко проверить простым дополнительным запросом.

Цитата:

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

Кстати, никто не обращал внимание, что критерии со статусом Hidden - не такие уж и невидимые?
Достаточно в форме расширенного фильтра вызвать расширенный фильтр (в 2009-й через комбинацию клавишь) и нажать Ok

Ух ты. Такое поведение нужно исправлять. Например так. На форме SysQueryForm, в методе init() датасурса Range

void init()
{

    super();

    selectRangeRecords = this.query().dataSourceNo(1).addRange(fieldnum(TmpSysQuery, RangeStatus));
    selectRangeRecords.value('!' + enum2str(RangeStatus::Hidden));

    selectRangeRecords.status(RangeStatus::Locked); // <<--
}

Цитата:

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

А если использовать не ExistsJoin, а InnerJoin?

О! Здравая идея. А для оптимизации тогда ещё можно задать addSelectionField со значением SelectionField:atabase по какому-нибудь полю индекса

[mazzy]

Цитата:

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

Простейшая задача: есть query по таблице CustTable с какими-то условиями.
Есть значение "КлиентАБВ".

Нужно проверить, есть ли запись с таким значением поля AccountNum в имеющемся query.

не проверял в аксапте но примерно так:

boolean findSuperCust(Query _srcQuery, CustAccount _custAccount = "КлиентАБВ")
{
    Query q = new Query(q); // создаем копию
    QueryRun qr;

    // устанавливаем новый критерий или меняем существующий
    findOrCreateRange_W(q.dataSourceTable(tablenum(custTable)),fieldnum(custTable, AccountNum), QueryValue(_custAccount));
    
    // выполняем запрос
    qr = new QueryRun(q);
    return qr.next();
}

будут побочные эффекты, если в исходном запросе установлено больше одного критерия на поле accountNum.

[S.Kuskov]

Цитата:

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

будут побочные эффекты, если в исходном запросе установлено больше одного критерия на поле accountNum.

А если ровно один? не будут?
Вы о каких эфектах?

В случае если пользовательский фильтр по полю accountNum имеет место быть, то тогда просто взять и заменить его на "КлиентАБВ" можно только если истинно Global::inRange(Range.value, "КлиентАБВ").
В общем случае пользовательских фильтров может быть несколько, значит проверить прийдётся их все, т.е. нужен цикл. ИМХО добавить ещё одну связку по exists join будет проще.

Ещё раз. Все эти извращения нужны если "пользовательский фильтр по полю accountNum имеет место быть". Если нет, то достаточно совета Jorj и mazzy

[mazzy]

Цитата:

Сообщение от S.Kuskov

А если ровно один? не будут?
Вы о каких эфектах?

Если ровно один, то findOrCreateRange_W изменит критерий на 'КлиентАБВ' по полю.
Если меньше одного, то findOrCreateRange_W добавит критерий 'КлиентАБВ' по полю.

А вот если больше одного, то findOrCreateRange_W изменит один из критериев (первый попавшийся) на 'КлиентАБВ'. Все критерии по этому полю будут действовать через ИЛИ.

Цитата:

Сообщение от S.Kuskov

В случае если пользовательский фильтр по полю accountNum имеет место быть, то тогда просто взять и заменить его на "КлиентАБВ" можно только если истинно Global::inRange(Range.value, "КлиентАБВ").

Хм...
А ведь точно.

[mazzy]

мне кажется что достаточно будет добавить ",КлиентАБВ", если критерий уже существует.

boolean findSuperCust(Query _srcQuery, CustAccount _custAccount = "КлиентАБВ")
{
    Query q = new Query(_srcQuery); // создаем копию
    QueryBuildRange qbr;
    QueryRun qr;

    // устанавливаем новый критерий или меняем существующий
    qbr = SysQuery::findOrCreateRange(q.dataSourceTable(tablenum(custTable)),fieldnum(custTable, AccountNum));
    qbr.value( queryRangeConcat(qbr.value(), _custAccount) ); // добавляем к уже существующему или устанавливаем вместо пустого

    // выполняем запрос
    qr = new QueryRun(q);
    return qr.next();
}

[mazzy]

похоже вот такой способ будет работать всегда.
но если на код клиента уже был установлен критерий, то этот способ будет работать медленно.

boolean findSuperCust(Query _srcQuery, CustAccount _custAccount = "КлиентАБВ")
{
    Query q = new Query(_srcQuery); // создаем копию
    QueryBuildRange qbr;
    QueryRun qr;
    CustTable custTable;

    // устанавливаем новый критерий только если раньше он был не установлен.
    qbr = SysQuery::findOrCreateRange(q.dataSourceTable(tablenum(custTable)),fieldnum(custTable, AccountNum));
    if( !qbr.value()  )
        qbr.value(queryValue(_custAccount));

    // выполняем запрос
    qr = new QueryRun(q);
    while( qr.next() )
    {
        custTable = qr.get(tablenum(CustTable));
        if( custTable.accountNum == _custAccount )
            return true;
    }
    return false;
}

[AndyD]

queryRangeConcat() - это условие 'или'

Кроме того, кто может поручиться, что ранее добавленное условие - это не расширенный фильтр?

[mazzy]

ок. убедили.

вариант S.Kuskov: приджойнить exist join тоже не подойдет. поскольку в запросе уже может быть join. http://msdn.microsoft.com/en-us/libr...36(AX.10).aspx

тогда остается только перебор записей в случае, если критерий на accountNum установлен?

[S.Kuskov]

Цитата:

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

тогда остается только перебор записей в случае, если критерий на accountNum установлен?

А чем не подходит такой вариант?

    boolean findSuperCust(Query _srcQuery, CustAccount _custAccount = "КлиентАБВ")
    {
        Query q = new Query(_srcQuery); // создаем копию
        QueryBuildDataSource qbds = q.dataSourceTable(tablenum(custTable));
        QueryBuildRange qbr;
        QueryRun qr;
        Range SuperCustRange = strfmt("(%1.%2 == %3)", qbds.name(), fieldStr(custTable, AccountNum));

        // устанавливаем новый критерий или меняем существующий
        qbr = SysQuery::findOrCreateRange(qbds ,fieldnum(custTable, DataAreaId));
        if (qbr.value())
            qbr.value(strfmt("(%1 && %2)", SuperCustRange, qbr.value()));
        else
            qbr.value(SuperCustRange);

        // выполняем запрос
        qr = new QueryRun(q);
        return qr.next();
    }

Я вижу один недостаток - ограничение на длину строки в Range.

[AndyD]

Цитата:

Сообщение от S.Kuskov

            qbr.value(strfmt("(%1 && %2)", SuperCustRange, qbr.value()));

Хм.
А что, уже стало возможно использовать совместно расширенный синтаксис фильтров и обычный?