Thread

Re: ON ERROR triggers

Vadim Mikheev <vmikheev@sectorbase.com> — 2002-01-04T19:48:26Z

> 2) Allow a transaction to be marked for rollback, in which case
>    it proceeds but rolls back at commit time. It is not possible

Sorry, can you explain one more time what's the point to continue
make changes in transaction which will be rolled back?

How about savepoints?

Vadim

Re: ON ERROR triggers

Holger Krug <hkrug@rationalizer.com> — 2002-01-07T07:48:51Z

On Fri, Jan 04, 2002 at 11:48:26AM -0800, Mikheev, Vadim wrote:
> > 2) Allow a transaction to be marked for rollback, in which case
> >    it proceeds but rolls back at commit time. It is not possible
> 
> Sorry, can you explain one more time what's the point to continue
> make changes in transaction which will be rolled back?

I think, I can.

The point is to collect comprehensive error reports, mainly about
failed modifications of complex structured data which is
created/modified concurrently by several workers in an optimistic
locking fashion. Because the data is so complex it won't help anybody
if you print out a message as "index xy violated by tuple ab". Hence I
want to collect all the errors to give the application/the user the
possibility to make an overall assessment about what has to be done to
avoid the error.

This is also the reason, why I will insert a DUPKEY into an index
after having marked the transaction for rollback (see my answer to
Jan's mail). I deem this will give more informative error reports. I
simply execute all, what the user wants to be done, and inform the
user about all the errors occurring, not only the first one.

Imagine CVS would inform you only about 1 conflict each time you asks to
be informed about potential conflicts. Wouldn't it be annoying ? For
sure, it would. Now think about databases.

> How about savepoints?

This would be my question to you: How about savepoints ?
Do they help to achieve what I want to achieve ?

-- 
Holger Krug
hkrug@rationalizer.com