Re: Грабли с кэшем данных
Меня больше интересует что по этому поводу думает Кальтенбруннер. Но он, как всегда, сохраняет молчание :)) Стабильные курсоры будут. Но скорее всего опционально. И не сегодня :-) Спасибо за лучик надежды, Отто : Коваленко Дмитрий.
Re: Грабли с кэшем данных
DY Стабильные курсоры будут. Но скорее всего опционально. Управляться параметрами транзакции, или рулиться конфигом? Это неважно, потому что требует 1% от основных усилий в данном направлении :-) По мне, такие вещи должны работать по умолчанию. Но возможно есть какие-то нюансы. Типа селекта из SP, которая добавляет новые записи в таблицу из которой она делает выборку :))) Коваленко Дмитрий.
Re: Грабли с кэшем данных
Стандарт тоже так считает. Но если это будет стоить каких-либо заметных тормозов, то лучше дефолтом оставить старое поведение. Я надеюсь, что когда это появится, у меня уже будет очередной аппарат и эти лишние телодвижения на уровне сервера мне будут по-барабану :))) Коваленко Дмитрий.
Re: Грабли с кэшем данных
On Fri, 08 Jan 2010 00:23:57 +0600, Kovalenko Dmitry dmitry.lipe...@gmail.com wrote: Предлагаю крайним сделать сервер - пусть создает стабильные курсоры. EUSUS. а что говорит стандарт по этому поводу?
Re: Грабли с кэшем данных
Предлагаю крайним сделать сервер - пусть создает стабильные курсоры. EUSUS. а что говорит стандарт по этому поводу? Меня больше интересует что по этому поводу думает Кальтенбруннер. Но он, как всегда, сохраняет молчание :)) Коваленко Дмитрий.
Re[2]: Грабли с кэшем данных
Превед! --- Предлагаю крайним сделать сервер - пусть создает стабильные курсоры. EUSUS. Вот мои 0.02 MDL - это проблемы клиента. Если клиент такой умный - пусть делает вставку в отдельной транзакции с returning rdb$db_key - и тогда уже выполняет манипуляции со своим собственным кэшем, как ему вздумается. Я думаю, что ничего страшного в данном поведении нет - это скорее фича кэша эксперта, чем его бага - но лучше спросить у Хвастунова, он точно скажет. А сервер тут не причём :P) P/S С новым годом всех! -- Best regards, Sergeymailto:gebele...@gmail.com
Re: Re[2]: Грабли с кэшем данных
Предлагаю крайним сделать сервер - пусть создает стабильные курсоры. EUSUS. но лучше спросить у Хвастунова, он точно скажет. Хаха. На 200% он скажет тоже самое - моя тут ни причем, ето все сервер А сервер тут не причём :P) Чтобы понять что как раз причем нужно попробовать самому покурить тему реализации универсального датасета на уровне компонент доступа. Универсального в том смысле, что запрос для этого датасета дается извне. И может быть каким угодно. Запрос select * from TABLE - это самый тривиальный случай. Причем покурить не теоритически типа можно вот так, а можно и вот так.. А по-настоящем ;-) --- Текущие решения я (и не только) озвучивал. С двумя транзакциями - это не всегда подходит. Может клиенту не хочется юзать две транзакции. С полной загрузкой ... многотонной таблицы ... провайдер такое выдержит, хотя и уйдет на некоторое время в себя. А вот к остальным прийдет мемори_оверфлоф :))) --- Так что, господа - проблема на уровне сервера : --- Коваленко Дмитрий.
Re: Грабли с кэшем данных
7. Идем обратно, в начало нашего множества. И там мы её тоже видим. Ясный пень, я понимаю почему это происходит. А я - нет, объясни На пустой таблице это делается так. 0. Выполняем запрос select * from TABLE. Фетч не делаем. 1. Юзер добавляет запись в гриде - Клиент добавляет запись во внутренний кэш - Клиент выполняет запрос INSERT INTO и запись попадает в таблицу 2. Юзер видит добавленную запись. 3. Юзер начинает движение вниз по гриду. - Клиент делает фетч и выбирает запись, которую мы добавили в п.2.2. И он её снова добавляет в кэш таким образом, одна и та же запись дважды фигурирует в кэше. --- В IBE с пустыми таблицами тест не провернешь. Он начинает делать фетчи чтобы заполнить видимую часть грида. Поэтому там надо забить в таблицу побольше данных. Чтобы, после того как мы добавим новую запись, он смог продолжить фетч и выбрать эту запись снова. Коваленко Дмитрий.
Re: Грабли с кэшем данных
7. Идем обратно, в начало нашего множества. И там мы её тоже видим. Ясный пень, я понимаю почему это происходит. А я - нет, объясни На пустой таблице это делается так. 0. Выполняем запрос select * from TABLE. Фетч не делаем. 1. Юзер добавляет запись в гриде - Клиент добавляет запись во внутренний кэш - Клиент выполняет запрос INSERT INTO и запись попадает в таблицу 2. Юзер видит добавленную запись. 3. Юзер начинает движение вниз по гриду. - Клиент делает фетч и выбирает запись, которую мы добавили в п.2.2. И он её снова добавляет в кэш таким образом, одна и та же запись дважды фигурирует в кэше. Т.е. в клиентском кеше ? В датасете ? И в чём проблемы идентифицировать отфетченную запись и оставить в кеше что-то одно ? И, главное, причём тут доработка со стороны сервера ? -- Хорсун Влад
Re: Грабли с кэшем данных
Т.е. в клиентском кеше ? В датасете ? И в чём проблемы идентифицировать отфетченную запись и оставить в кеше что-то одно ? В чем проблемы, говоришь? Бугага. Да во всем. И, главное, причём тут доработка со стороны сервера ? Пусть он (курсор) не возвращает записи, которые добавились после начала выполнения запроса. Вообще говоря, тут надо по другому сказать - Пусть курсор не видит изменения, которые произошли в БД после его открытия. Коваленко Дмитрий.
Re: Грабли с кэшем данных
Kovalenko Dmitry ... Т.е. в клиентском кеше ? В датасете ? И в чём проблемы идентифицировать отфетченную запись и оставить в кеше что-то одно ? В чем проблемы, говоришь? Бугага. Да во всем. Научить PK объявлять и работать с ним ? :-D Кстати, тот самый, достаточно редкий случай, когда DBKEY может помочь. И, главное, причём тут доработка со стороны сервера ? Пусть он (курсор) не возвращает записи, которые добавились после начала выполнения запроса. Вообще говоря, тут надо по другому сказать - Пусть курсор не видит изменения, которые произошли в БД после его открытия. Ну, жди... :) -- Хорсун Влад
Re: Грабли с кэшем данных
Ну, жди... :) Дык, это мое перманентное состояние :-) Чередуемое с периодами беснования :-))) Коваленко Дмитрий.
Re: Грабли с кэшем данных
0. Выполняем запрос select * from TABLE. Фетч не делаем. 1. Юзер добавляет запись в гриде - Клиент добавляет запись во внутренний кэш - Клиент выполняет запрос INSERT INTO и запись попадает в таблицу Вот тут и косяк. Иделогически датасет дожен либо сделать предварительно FetchAll или Refresh после инсерта. Либо перед первой вставкой форсированно загружать все множества. И тут тоже можно нарваться :) Про рефрешЪ я не думал - потому что тут думать нечего. Не катит :-)) Если инсерт ещё и с сохранением ордера, то ситуация ещё более очевидна. Кругом засада :)) --- Предлагаю крайним сделать сервер - пусть создает стабильные курсоры. EUSUS. Коваленко Дмитрий.
Грабли с кэшем данных
Привет всем. С наступившим, типа. Я тут накатал тест, результаты которого меня заставили задуматься :) В эксперте это воспроизводится таким образом. 1. Таблица с одной INTEGER-колонкой 2. Заполняем таблицу execute block as declare variable n integer; begin n=1; while(n=10)do begin insert into TEST_TABLE_3197 (ID) VALUES (:n); n=n+1; end end 3. Открываем данные таблицы. У меня эксперт вывел первые 39 записей. 4. Вставляем (в гриде) новую запись (ID=999 999) 5. Нажимаем Ctrl+End для перехода на последнию запись 6. И видим нашу добавленную запись с ID=999 999 7. Идем обратно, в начало нашего множества. И там мы её тоже видим. Ясный пень, я понимаю почему это происходит. И не спасет никакой уровень изоляции. Ну только если вставку делать в другой транзакции. А читать в повторяемом чтении. Но это не всегда хорошо. Либо перед первой вставкой форсированно загружать все множества. И тут тоже можно нарваться :) Я правильно понимайт, что спасет только (та самая что и для insert from select) доработка со стороны сервера? :))) Коваленко Дмитрий.
Re: Грабли с кэшем данных
Kovalenko Dmitry ... 7. Идем обратно, в начало нашего множества. И там мы её тоже видим. Ясный пень, я понимаю почему это происходит. А я - нет, объясни -- Хорсун Влад
