Hello, Дмитрий!
Качановский Дмитрий wrote:
update оператор сложный, т.е. его выполнение происходит в несколько этапов
(получение записи/получение полей/сообщение всем "счас буду менять"/
изменение/сообщение всем "изменил")
где ты это взял, про "сообщения"? update/delete тупо МОДИФИЦИРУЕТ
запись которая попадает под условие, никому ничего не сообщая, вообще.
Он или успешно создает новую версию записи, или обламывается при
обнаружении не-committed версии (или committed, но которую нельзя
видеть в snapshot).
> а про то в какой последовательности это
происходит нигде найти не удалось (весь ibase перерыл) , и как это зависит
от параметров транзакций
ыыыы. караул. ты не в Москве? Приходи завтра, я тебе за полчаса все
объясню, только чтобы ты тут перестал мучить :-)
про селект есть пояснения как он будет работать в разных транзакциях, а вот
про update ничегошеньки
все то же самое.
вначале оптимизатор строит план запроса.
потом (точно так же как селект)
1. если это натурал, перебирает записи и по ходу их обновляет (селект -
читает)
2. если это выборка по индексу, то строится массив номеров записей
выбранный из индекса (по условию), затем массив сортируется,
и по нему выбираются записи. Доп. проверка записи производится
если по какому-то столбцу не было индекса.
апдейт - обновляет, селект - читает
3. собственно, все.
если при очередном обновлении происходит облом по блокировке,
то через savepoints все произведенные изменения (до начала
оператора update) откатываются.
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
