PostgreSQL и автоматический rollback транзакции после ошибки.

[Пантер]

Такая нехорошая ситуёвина. Если в пределах транзакции произошла ошибка (допустим пытаюсь дропнуть индекс, а его нет), транзакция автоматом роллбекается, что есть очень плохо. Можно как-нибудь этого избежать?

[BaltikS]

Нет, транзакция для этого и нужна, чтобы откатить целый блок. А если ошибка вызывается в одном запросе, то откатывается весь блок. Можно попробовать запрос выполнить вне транзакции или в другой транзакции.

[Пантер]

Да без базара, я САМ откачу, если нужно будет. Но делать это за меня - ппц. Предаставь, что есть куча диалогов на одну транзакцию, и в, допустим, четвертом диалоге пользователь не указывает переменную, которая не должна быть NULL, в этом месте нужно просто вывести ошибку и дать исправить, но не откатывать транзакцию и выбивать ошибки во всех нижних диалогах. Хотя, возможно, я что-то не так понимаю.

[BaltikS]

Что то я тоже не понимаю, а нельзя ли сделать самому проверку на NULL в диалоге? А не средствами СУБД?
Я например сначала ввёл все данные во всех последовательно 4-х диалогах, а потом все данные в транзакцию запихнул без всяких ожиданий ввода...

[Пантер]

Да придется так. Вот только код разрастется. Вроде на firebird'е не так было, хотя утверждать не буду.

[Rcus]

Такая нехорошая ситуёвина. Если в пределах транзакции произошла ошибка (допустим пытаюсь дропнуть индекс, а его нет), транзакция автоматом роллбекается, что есть очень плохо. Можно как-нибудь этого избежать?

Ошибки с DDL запросами можно игнорировать добавлением IF [NOT] EXISTS, а DML оборачивать в PL/pgSQL функции, обрабатывая исключения в блоке EXCEPTION
 и проверять код возврата в вызывающем коде

[WW]

Да без базара, я САМ откачу, если нужно будет. Но делать это за меня - ппц. Предаставь, что есть куча диалогов на одну транзакцию, и в, допустим, четвертом диалоге пользователь не указывает переменную, которая не должна быть NULL, в этом месте нужно просто вывести ошибку и дать исправить, но не откатывать транзакцию и выбивать ошибки во всех нижних диалогах. Хотя, возможно, я что-то не так понимаю.

Никогда не делай диалоги в транзакции. Эт не хорошая практика.
И почитай про SAVEPOINT. Иногда помогает

[panAlexey]

Никогда не делай диалоги в транзакции. Эт не хорошая практика.

+писот. проверенно практикой...

[Tonal]

А ты явно управляешь транзакциями?
Может где можно сказать драйверу. чтобы не самовольничал?
Ну и в Firebird-е управление транзакциями - всегда пользовательское а что в PG я не в курсе - нужно читать доки.

Ну и про диалоги - я придерживаюсь правила, что пишущую транзакцию нужно стартовать только тогда, когда все данные уже доступны и по максиму верифицированы. Тогда они получаются короткими - соответственно гораздо меньше шансов нарваться на конфликт.

[Пантер]

Хм. Как бы объяснить... В первом диалоге сразу создается документ, его id нужен для других диалогов. Если не пользоваться транзакциями, то в код нужно добавить удаление документа, если юзверь нажал отмену. Да и не очень хорошо будет, если документ отобразиться у других юзверей пока его толком еще не создали.

[Tonal]

Не, ты не понял.
Я создаю в таких случаях создаю все объекты на клиенте, не трогая базу.
А вот когда нажимается финальный Save, максимально возможно валидируются все объекты, стартуется транзакция, всё скопом пишется в базу, транзакция коммитится.
Ежели вышел облом по ограничениям базы, то можно и перезапустить процесс с нужного места со всеми введёнными данными.

А с длинными транзакциями есть практически неустранимая бяка, когда товарищ, заполняющий данные, пошёл покурить и не вернулся, оставив диалог и транзакцию висеть блокируя работу остальных.

[Пантер]

У меня так не получится. Добавил проверку на правильность ввода перед сохранением в базу.

[WW]

У меня так не получится. Добавил проверку на правильность ввода перед сохранением в базу.

"Никогда не говори никогда" (с)
Уже было 1000 раз, когда кто-то просто отвлекся на тел. звонок (клиента).
И весь офис ищет этого "шалуна", т.к. работа просто встала...