"Vlad Khorsun" ...
Ладно, исходя из предположения, что "индексы при удалении не сразу
перестраиваются" делаем финт ушами - перед удалением записи в
транзакции No.1 проводим апдейт:
update BoothReservation set pDate = (CURRENT_DATE - 365*100 - ID)
where ID = 4;
delete from BoothReservation where ID = 4;
Т.е. тупо апдейтим поле, входящее в уникальный индекс каким-нибудь
левым значением - в данном случае делаем минус 100 лет, минус ID
(чтобы разные записи не пересекались).
Работает. Теперь вставка "удалённой" записи в транзакции No.2 проходит
без коммита транзакции No.1. Что и требовалось получить.
Не должно это работать. Проверю.
Работает. А с сейвпойнтом не работает. Так что шансов нарушить уникальность
вроде бы нет.
Вот краткое объяснение "на пальцах" того, что там происходит :
Вариант insert + update в одной тр-ции : внутри движка по окончанию update'а
идёт очистка сейвпойнта самого update'а и его данные переносятся на предыдущий
сейвпойнт. Это сейвпойнт insert'а, который эту запись уже видел. Посему ключ,
вставленный insert'ом удаляется немедленно (иначе мы его уже никогда не найдём).
Вариант insert + savepoint + update в одной тр-ции : внутри движка по
окончанию update'а
идёт очистка сейвпойнта самого update'а и его данные переносятся на предыдущий
сейвпойнт. Это юзерский сейвпойнт, который эту запись не видел. Посему ключ,
вставленный insert'ом остаётся на месте и будет удалён позже, при коммите
юзерского
сейвпойнта.
Влад
