Thread: Future development
Hi All, It's been a while now since we released the 07.03.0260 build of the driver for evaluation as a possible basis for future versions of psqlODBC. If you can't remember what I'm talking about, please take a peek at http://archives.postgresql.org/pgsql-odbc/2006-02/msg00131.php We haven't had any comments either for or against basing future versions of psqlODBC on this branch despite it being downloaded over 36,000 times(!). I'd therefore like to ask if anyone has any thoughts either way on the subject please post to the list so a decision can be made and normal development can resume! Regards, Dave.
> -----Original Message----- > From: "Tomas Skäre" [mailto:tomas@nocrew.org] > Sent: 17 March 2006 12:26 > To: Dave Page > Cc: pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Future development > > Dave Page <dpage@vale-housing.co.uk> writes: > > > We haven't had any comments either for or against basing > future versions of > > psqlODBC on this branch despite it being downloaded over > 36,000 times(!). > > I'd therefore like to ask if anyone has any thoughts either > way on the > > subject please post to the list so a decision can be made and normal > > development can resume! > > I don't really have an opinion about the methods of implementation, > but I still choose the 7.3 experimental branch for the single reason > that it still has Updatable cursors which I need where I use it. OK, thanks for the feedback. Anyone else? Luf, Anoop? Regards, Dave.
Dave Page wrote: >>> We haven't had any comments either for or against basing >> future versions of >>> psqlODBC on this branch despite it being downloaded over >> 36,000 times(!). >>> I'd therefore like to ask if anyone has any thoughts either >> way on the >>> subject please post to the list so a decision can be made and normal >>> development can resume! >> I don't really have an opinion about the methods of implementation, >> but I still choose the 7.3 experimental branch for the single reason >> that it still has Updatable cursors which I need where I use it. > > OK, thanks for the feedback. Anyone else? 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. :-/ Cheers, Bart
Dave Page <dpage@vale-housing.co.uk> writes: > We haven't had any comments either for or against basing future versions of > psqlODBC on this branch despite it being downloaded over 36,000 times(!). > I'd therefore like to ask if anyone has any thoughts either way on the > subject please post to the list so a decision can be made and normal > development can resume! I don't really have an opinion about the methods of implementation, but I still choose the 7.3 experimental branch for the single reason that it still has Updatable cursors which I need where I use it. Tomas
Fri, Mar 17, 2006 at 12:40:53PM -0000, Dave Page napsal(a): > > -----Original Message----- > > From: "Tomas Skäre" [mailto:tomas@nocrew.org] > > > > Dave Page <dpage@vale-housing.co.uk> writes: > > > > > We haven't had any comments either for or against basing > > > future versions of > > > psqlODBC on this branch despite it being downloaded over > > > 36,000 times(!). > > > I'd therefore like to ask if anyone has any thoughts either > > > way on the > > > subject please post to the list so a decision can be made and normal > > > development can resume! > > > > I don't really have an opinion about the methods of implementation, > > but I still choose the 7.3 experimental branch for the single reason > > that it still has Updatable cursors which I need where I use it. > > OK, thanks for the feedback. Anyone else? Luf, Anoop? I think we may continue in 7.3 branch becouse it is more powerful version. I stopped my development becouse I'm not sure if 7.3 branch is ready for next steps right now. And I don't want spend a lot of time on 8.1 branch. Regards, Luf
> 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. Regards, Luf
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
Hello I copy&paste here second thread which is related to this: > >This is backend related. I assume you use autocommit=off. In this > >case backend doesn't allow next commands after failed one in > >one transaction. > > I get what autocommit does when I haven't started a transaction, but > what does "autocommit" mean when I'm inside a manually started transaction? When you start transaction manually you have to finish it manually. I see no difference in ending transactions. > >08.00.0102 driver calls automatic rollback (if I remember it right). > >Some users voted againist it. And I agreed with them. When programmer > >manage the transaction he may also manage errors. > > Yes. But that also means that he needs to get a choice on whether to > continue or not. The 8.01 driver forces the programmer to rollback, > which is not very nice. You have the choice. You could use savepoints (this is the way used by 7.3 experimental driver). When driver uses savepoints automatically before each statement it has to be slow down. > >I see no reason to continue transaction when something in it failed. > >Transaction may be atomic. All inside is ok or no change happens. > >It sounds quite odd for me that another RDBMS do it another way. > > Well, on other DBMSes the statements themselves seem to act like small > transactions themselves. If a single statement fails, you can try and > finish your transaction in another way, or you can roll it back. Your > choice. Ok. You're right. I have used too strong words. Wed, Mar 22, 2006 at 01:38:41PM +0100, Bart Samwel napsal(a): > 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 It gives you the choice ;-) but not hidden one. > 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. Maybe this could be good for writing DB applications for more RDBMS? Thanks for disscussion (I hope we will continue). You show me another point of view. Regards, Luf
Ludek Finstrle wrote: > Hello > > I copy&paste here second thread which is related to this: > >>> This is backend related. I assume you use autocommit=off. In this >>> case backend doesn't allow next commands after failed one in >>> one transaction. >> I get what autocommit does when I haven't started a transaction, but >> what does "autocommit" mean when I'm inside a manually started transaction? > > When you start transaction manually you have to finish it manually. > I see no difference in ending transactions. ACK. >>> 08.00.0102 driver calls automatic rollback (if I remember it right). >>> Some users voted againist it. And I agreed with them. When programmer >>> manage the transaction he may also manage errors. >> Yes. But that also means that he needs to get a choice on whether to >> continue or not. The 8.01 driver forces the programmer to rollback, >> which is not very nice. > > You have the choice. You could use savepoints (this is the way used by > 7.3 experimental driver). When driver uses savepoints automatically > before each statement it has to be slow down. Of course it will be slightly slower. But I think savepoints are not that slow, their big cost is at rollback time. At least it's nice to have it as an option, as in the 7.3 driver. >>> I see no reason to continue transaction when something in it failed. >>> Transaction may be atomic. All inside is ok or no change happens. >>> It sounds quite odd for me that another RDBMS do it another way. >> Well, on other DBMSes the statements themselves seem to act like small >> transactions themselves. If a single statement fails, you can try and >> finish your transaction in another way, or you can roll it back. Your >> choice. > > Ok. You're right. I have used too strong words. Glad you see things my way. ;-) > Wed, Mar 22, 2006 at 01:38:41PM +0100, Bart Samwel napsal(a): >> 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 > > It gives you the choice ;-) but not hidden one. You mean I can set savepoints manually. :-) >> 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. > > Maybe this could be good for writing DB applications for more RDBMS? For portability it would definitely be nice if the driver supports the other RDBMS drivers' behaviour. > Thanks for disscussion (I hope we will continue). You show me another > point of view. I'll keep an eye on the discussion. Pointing it in the right direction can save me a whole lot of work later. :-) --Bart
Bart Samwel <bart@samwel.tk> writes:
> Ludek Finstrle wrote:
>> 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.
Really? Considering that there was no backend support at all for such a
thing back in 7.*, this seems improbable.
regards, tom lane
> -----Original Message----- > From: pgsql-odbc-owner@postgresql.org > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Tom Lane > Sent: 22 March 2006 14:54 > To: Bart Samwel > Cc: Ludek Finstrle; pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Future development > > Bart Samwel <bart@samwel.tk> writes: > > Ludek Finstrle wrote: > >> 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. > > Really? Considering that there was no backend support at all > for such a > thing back in 7.*, this seems improbable. Not in the backend, but the ODBC REL-07_03_ENHANCED branch has superior savepoint support over CVS tip. Regards, Dave.