08.06.2012, 07:15 | #1 |
MCTS
|
Как узнать, подходит ли Record к Query?
Допустим, есть у вас объект Query. И есть еще запись Record. Как красиво проверить факт того, что эта запись Record содержится в одной из записей данного Query?
|
|
08.06.2012, 08:12 | #2 |
Участник
|
Добавить в Query условие фильтрации по RecId и выполнить запрос. Если запись вернулась, то запись Record содержится в Query
Чтобы запрос выполнился ещё быстрее можно его преобразовать (убрать сортировку, группировку, выборку лишних значений) как в методе sysQuery::countPrim(). Если задачу можно свести к проверке "Попадает ли значение в фильтр Range?", то можно воспользоваться функцией Global::inRange(). |
|
|
За это сообщение автора поблагодарили: mazzy (5), Eldar9x (3), kornix (2). |
08.06.2012, 08:12 | #3 |
Участник
|
Цитата:
А если запись прочитана в одной транзакции, а в другой изменена это будет считаться той-же записью или новой? Насчет уровней изоляции ничего в условии задачи не сказано... В качестве решения видится следующее (это мысли, на базе не пробовал). В запросе вытаскивать максимальную дату создания (модификации). При проверке записи проверять на соответствие условиям выборки и на то, что дата создания (модификации) не больше контрольной. Это правда не гарантирует 100% точность, если нет уверенности что все вставки в таблицу правильно устанавливают время создания (модификации). |
|
08.06.2012, 08:25 | #4 |
Участник
|
Ещё иедя появилась. Можно превратить курсор постоянной таблицы во временный буфер методом common.setTmp(). Вставить в этот временный буфер интересующую строку. Подсунуть этот временный буфер в QueryRun при помощи метода QueryRun.SetRecord(). И выполнить запрос по временной таблице, состоящей из одной строки.
Если запрос состоит из соединения нескольких таблиц, то процедуру замены постоянного курсора на временный в общем случае нужно будет сделать для всех таблиц. Иначе можно получить ошибку Временные таблицы должны быть вложенными... Да и производительность только тогда и улучшится. Т.е. идея в том чтобы выполнить запрос не в БД а в оперативной памяти на клиенте. To AlexMoskvichev: На сколько я понял речь о том, что Query ещё не выполнен, а только сконструирован. Последний раз редактировалось S.Kuskov; 08.06.2012 в 08:32. |
|
|
За это сообщение автора поблагодарили: Logger (2). |
08.06.2012, 09:03 | #5 |
MCP
|
Цитата:
2. Если queryRun.next() от нового query вернет запись - значит запись попадает в Query Источник |
|
|
За это сообщение автора поблагодарили: coolibin (1), S.Kuskov (1), AlexMoskvichev (1). |
08.06.2012, 10:50 | #6 |
MCTS
|
Спасибо!
|
|
08.06.2012, 14:47 | #7 |
Мрачный тип
|
Если походить абстрактно (т.е. нам не известен заранее ни сам Query, ни Record) то :
1) Query может состоять из более чем одного датасорса, и в нем может быть, а может и не быть датасорса по таблице, соответсвующей Record 2) В структуре Query может быть более одного датасорса по таблице соответсвующей Record Если первый пункт можно разрешить, то при положительном втором пункте ответ на поставленный в теме вопрос становится неопределенным
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
Теги |
queryrun, полезное |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|