Re: possible bug in DB/pgsql.php

fabrizio.ermini@sysdat.it wrote: > > On 18 Feb 2001, at 16:11, Stig S. Bakken wrote: > > > > So, at the moment, DB_pgsql does only half of the work. To do it > > > full, there should be an explicit "begin" somewhere. If this cannot > > > be "user required" as i suggested in my previous message, the > > > hard part is finding where... > > > > > Ok, what if we take away the implicit "commit" after each query when > > auto-commit is on, and add an implicit "begin" before each query when > > auto-commit is off instead? I would like to avoid having more than one > > transaction paradigm. :-) > > > Yep, this I understand... doing that way things could work, though > in a little hackish way. > i.e. in this way if I'd do (syntax is really pseudo, I've not the > sources at hand): > > $db->auto_commit(off); > /* start transaction */ > $db->query(some_query); <- this does a "begin" > ...some logic... > $db->query(some_other_query); <- this does another "begin", > warning message > /* close transaction */ > $db->commit(); > > For the moment, this would work, since multiple begins raise only > "NOTICEs" and don't break anything (and you've already showed > you know how to silence them :-)), but I wouln't choose this > solution so steadfastly. It's more than possible that future versions > of pgsql raise errors instead of warnings, or even open a nested > transaction (OK, this is not in the TODO list for at least next year, > so we can relax for the moment...), and I'm not even sure that all > _existing_ versions of pgsql digest the "multiple" begin without > getting irritated. > Maybe the problem can be solved using some sort of hidden "flag" > that tells us if we are in "transaction mode" or not, and using this > flag to send a "begin" or not. > > i.e. the code for the query method could be something like: > > function query($string) > { > ... > if (($this->autocommit==0) && (!$this->trans_block)) > { > pg_exec($this->conn_id,"BEGIN WORK"); > $this->trans_block=TRUE; > } > ... do query ... > } > > function commit() > { > if ($this->trans_block) > { > pg_exec($this->conn_id,"COMMIT WORK"); > $this->trans_block=FALSE; > } > else > { > error("Nothing to commit!"); > } > } > > rollback() would be symmetrical, and $trans_block should be init to > FALSE in the costructor. (again, never mind the sintax, I'm just > pseudocoding... hope to be readable %-)). > > owever, I'm using hypotethical tense here because AFAIU PEAR > db object can be used with multiple connections (that is, for each > page we should have just one $db object but we could have many > $conn_id, right?), and I'm afraid this way things won't work. Unless, > instead of using a simple boolean flag, we use this $trans_block > thingy to store the connection id of each backend that has a > "pending" connection (but then it could not be a scalar any more). > So the test to do in the pre-query part should be: > > -"Do I have the present connection in the list of pending transaction > blocks?" > { > YES: { "Skip the BEGIN statement" } > NO: { "Issue the BEGIN statement on the present connection" > "Add the present connection to the list of pending ones"} > > And, simmetrically, a commit or rollback should remove the > connection from the list of pending transactions. > > Hmm, maybe I'm straying too far...I'm not too content of my own > suggestions. Your turn... I like this idea. We might even set up a counter for the number of operations in a transaction, and only issue "BEGIN" when this counter == 0. Thanks a lot for your input! - Stig