|
|
| Тема |
 Re: окей [re: wqw] |
|
| Автор |
Dakota (erotoman) |
|
| Публикувано | 16.12.09 13:34 |
|
|
|
В отговор на:
... втория INSERT не се ли прави ROLLBACK до имплицитен SAVEPOINT преди него
Не. Просто от този момент нататък статутът на цялата транзакция става провален. Сървърът ти гарантира, че транзакцията или ще мине цялата, или изобщо няма да мине - т.нар. атомарност.
При MySQL и Oracle тази гаранция от страна на сървъра отсъства, т.е. отговорността за атомарността на транзакциите е оставена изцяло в ръцете на клиента.
С други думи, транзакциите в PostgreSQL са атомарни, докато в MySQL и Oracle могат да бъдат атомарни.
Относно това откъде тръгна всичко, забележката на salle беше правилна, т.е. проблемът наистина е A-то, а не C-то. Но както вече отговорих и на него, оригиналната ситуация, в която се натъкнах на това поведение беше с две таблици и референтен ключ, т.е. след завършването на транзакцията в едната таблица (photo) имаше снимки за кандидата, а в самата таблица с кандидатите (candidate) нямаше никой.
Е, оказа се, че не съм указал правилно референтния ключ, т.е. такъв не е имало изобщо. Просто при създаването на таблицата photo бях указал единствено candidate_sid int not null references candidate по навик от PostgreSQL, където това по подразбиране прави и foreign key constraint към първичния ключ на candidate, а в MySQL това не е така и трябваше изрично да го създам и съответния constraint.
"Договор, подписан с Русия, струва по-малко от хартията, върху която е написан!" - Бисмарк
| |
| |
| 
|
|
