From: | Bart Samwel <bart(at)samwel(dot)tk> |
---|---|
To: | Ludek Finstrle <luf(at)pzkagis(dot)cz> |
Cc: | pgsql-odbc(at)postgresql(dot)org |
Subject: | Re: Future development |
Date: | 2006-03-22 12:38:41 |
Message-ID: | 44214551.5060202@samwel.tk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-odbc |
Ludek Finstrle wrote:
>> I for one can't live without the "Level of rollback on errors" feature
>> of the 7.3 experimental branch. I don't care about which branch is used,
>> as long as this feature is in there -- the 8.1 branch doesn't work for
>> me at all. :-/
>
> Could you explain me the "Level of rollback on errors"? I think that
> when programmer doesn't use autocommit mode he want react on errors
> himself.
Like I said in my other message, the 8.01 driver doesn't give me a
choice in how to react on errors at all: it forces me to rollback the
complete transaction. I want to have a choice in that. The 7.03 driver
allows me to set the "Level of rollback on errors" to "Statement", which
means that only the failed statement is rolled back, and *I* then have
the choice of whether I want to rollback the remainder of the
transaction as well, or that I want to continue / try something else.
Another example of a situation where the per-statement rollback on
errors is wanted. Situation sketch: we have a client-side object model
with a generic persistence layer that stores the objects in a SQL
database. When we save changes, we try to store all of the objects
WITHOUT deferring constraints, even though there may be circular
references etcetera. The reason for not deferring constraints is that we
want to be able to tell the user which objects are the cause of
constraint violations, something which isn't possible when you simply
get "constraint XXX violated" at commit time. So, what we do is, we try
to store every object, skipping any that fail, then we try the failed
ones again, as long as the set of objects gets smaller. Then only at the
end do we try and defer constraints in order to store the last ones. But
if we can't deliberately try statements, knowing that they might fail
(atomically), this doesn't work. It works on all other databases that we
support, it works on PostgreSQL with the 7.03 driver with "Level of
rollback on errors" set to "Statement", it just doesn't work with the
8.01 driver because it will force us to roll back the transaction.
Cheers,
Bart
From | Date | Subject | |
---|---|---|---|
Next Message | juanudo | 2006-03-22 12:39:33 | Re: IM004-unixODBC |
Previous Message | Dave Page | 2006-03-22 12:22:05 | Re: Future versions of psqlODBC |