|
From: <no...@so...> - 2002-05-27 10:38:32
|
Bugs item #561019, was opened at 2002-05-27 10:38 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885 Category: DB_SQL Group: current CVS Status: Open Resolution: None Priority: 5 Submitted By: Marco Pratesi (pratesi) Assigned to: Nobody/Anonymous (nobody) Summary: db_pgsql.inc: lock() causes a warning Initial Comment: With the PostgreSQL class, the following code causes a warning: $qid = new DB_Sql(); $qid->lock("tablename"); The warning is: Warning: Supplied argument is not a valid PostgreSQL link resource... This is due to the fact that in this case the constructor issues an empty query, that causes a "return 0" without issuing "$this-connect()". When lock() is requested, the following line is executed: $result = pg_Exec($this->Link_ID, "lock table $table"); but $this->Link_ID is not a valid link, as connect() has not been executed yet. The problem could be solved using $this->query() instead of pg_Exec(), in analogy to what is done in db_mysql.inc, as in the following: $result = $this->query("lock table $table"); ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885 |
|
From: <no...@so...> - 2002-07-03 21:05:44
|
Bugs item #561019, was opened at 2002-05-27 05:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885 Category: DB_SQL Group: current CVS Status: Open Resolution: None Priority: 5 Submitted By: Marco Pratesi (pratesi) Assigned to: Nobody/Anonymous (nobody) Summary: db_pgsql.inc: lock() causes a warning Initial Comment: With the PostgreSQL class, the following code causes a warning: $qid = new DB_Sql(); $qid->lock("tablename"); The warning is: Warning: Supplied argument is not a valid PostgreSQL link resource... This is due to the fact that in this case the constructor issues an empty query, that causes a "return 0" without issuing "$this-connect()". When lock() is requested, the following line is executed: $result = pg_Exec($this->Link_ID, "lock table $table"); but $this->Link_ID is not a valid link, as connect() has not been executed yet. The problem could be solved using $this->query() instead of pg_Exec(), in analogy to what is done in db_mysql.inc, as in the following: $result = $this->query("lock table $table"); ---------------------------------------------------------------------- >Comment By: Chris Johnson (chaska) Date: 2002-07-03 16:05 Message: Logged In: YES user_id=279065 I thought one of our fearless programmers had gone through the db_* classes and made them more uniform? Or was a I dreaming? ..chris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885 |
|
From: <no...@so...> - 2002-07-03 21:46:19
|
Bugs item #561019, was opened at 2002-05-27 20:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885 Category: DB_SQL Group: current CVS Status: Open Resolution: None Priority: 5 Submitted By: Marco Pratesi (pratesi) Assigned to: Nobody/Anonymous (nobody) Summary: db_pgsql.inc: lock() causes a warning Initial Comment: With the PostgreSQL class, the following code causes a warning: $qid = new DB_Sql(); $qid->lock("tablename"); The warning is: Warning: Supplied argument is not a valid PostgreSQL link resource... This is due to the fact that in this case the constructor issues an empty query, that causes a "return 0" without issuing "$this-connect()". When lock() is requested, the following line is executed: $result = pg_Exec($this->Link_ID, "lock table $table"); but $this->Link_ID is not a valid link, as connect() has not been executed yet. The problem could be solved using $this->query() instead of pg_Exec(), in analogy to what is done in db_mysql.inc, as in the following: $result = $this->query("lock table $table"); ---------------------------------------------------------------------- >Comment By: Richard Archer (richardarcher) Date: 2002-07-04 07:46 Message: Logged In: YES user_id=279311 I did a lot of work on some of the db classes (MySQL, OCI8, ODBC come to mind). But I don't have most of those other databases running to test with. I think you'll find most of my work is in the devel tree only. I wasn't willing to commit untested code to the -stable tree. For example, the odbc driver in devel has *heaps* of improvements and bug fixes. It even implements lock(). While I did have an ODBC datasource at the time, I wasn't willing to commit a 500 line patch to -stable based on my development testing alone. Maybe we should just bite the bullet and commit this stuff to -stable and then fix any problems which arise. ---------------------------------------------------------------------- Comment By: Chris Johnson (chaska) Date: 2002-07-04 07:05 Message: Logged In: YES user_id=279065 I thought one of our fearless programmers had gone through the db_* classes and made them more uniform? Or was a I dreaming? ..chris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885 |
|
From: <no...@so...> - 2002-07-03 21:56:39
|
Bugs item #561019, was opened at 2002-05-27 06:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885 Category: DB_SQL Group: current CVS Status: Open Resolution: None Priority: 5 Submitted By: Marco Pratesi (pratesi) Assigned to: Nobody/Anonymous (nobody) Summary: db_pgsql.inc: lock() causes a warning Initial Comment: With the PostgreSQL class, the following code causes a warning: $qid = new DB_Sql(); $qid->lock("tablename"); The warning is: Warning: Supplied argument is not a valid PostgreSQL link resource... This is due to the fact that in this case the constructor issues an empty query, that causes a "return 0" without issuing "$this-connect()". When lock() is requested, the following line is executed: $result = pg_Exec($this->Link_ID, "lock table $table"); but $this->Link_ID is not a valid link, as connect() has not been executed yet. The problem could be solved using $this->query() instead of pg_Exec(), in analogy to what is done in db_mysql.inc, as in the following: $result = $this->query("lock table $table"); ---------------------------------------------------------------------- >Comment By: nathan hruby (nhruby) Date: 2002-07-03 17:56 Message: Logged In: YES user_id=19736 > Maybe we should just bite the bullet and commit this stuff > to -stable and then fix any problems which arise. Yes please :) That's what the -pre's are for.. to suss out the bugs by the advertursome and intelligent users before releasing to the masses. ---------------------------------------------------------------------- Comment By: Richard Archer (richardarcher) Date: 2002-07-03 17:46 Message: Logged In: YES user_id=279311 I did a lot of work on some of the db classes (MySQL, OCI8, ODBC come to mind). But I don't have most of those other databases running to test with. I think you'll find most of my work is in the devel tree only. I wasn't willing to commit untested code to the -stable tree. For example, the odbc driver in devel has *heaps* of improvements and bug fixes. It even implements lock(). While I did have an ODBC datasource at the time, I wasn't willing to commit a 500 line patch to -stable based on my development testing alone. Maybe we should just bite the bullet and commit this stuff to -stable and then fix any problems which arise. ---------------------------------------------------------------------- Comment By: Chris Johnson (chaska) Date: 2002-07-03 17:05 Message: Logged In: YES user_id=279065 I thought one of our fearless programmers had gone through the db_* classes and made them more uniform? Or was a I dreaming? ..chris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885 |
|
From: <no...@so...> - 2002-07-03 22:15:03
|
Bugs item #561019, was opened at 2002-05-27 05:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885 Category: DB_SQL Group: current CVS Status: Open Resolution: None Priority: 5 Submitted By: Marco Pratesi (pratesi) Assigned to: Nobody/Anonymous (nobody) Summary: db_pgsql.inc: lock() causes a warning Initial Comment: With the PostgreSQL class, the following code causes a warning: $qid = new DB_Sql(); $qid->lock("tablename"); The warning is: Warning: Supplied argument is not a valid PostgreSQL link resource... This is due to the fact that in this case the constructor issues an empty query, that causes a "return 0" without issuing "$this-connect()". When lock() is requested, the following line is executed: $result = pg_Exec($this->Link_ID, "lock table $table"); but $this->Link_ID is not a valid link, as connect() has not been executed yet. The problem could be solved using $this->query() instead of pg_Exec(), in analogy to what is done in db_mysql.inc, as in the following: $result = $this->query("lock table $table"); ---------------------------------------------------------------------- >Comment By: Chris Johnson (chaska) Date: 2002-07-03 17:15 Message: Logged In: YES user_id=279065 I say go for it. I think getting a packaged pre-release out the door is more important at this point in time than trying to scare up the people and resources to do that kind of coverage testing. ..chris ---------------------------------------------------------------------- Comment By: nathan hruby (nhruby) Date: 2002-07-03 16:56 Message: Logged In: YES user_id=19736 > Maybe we should just bite the bullet and commit this stuff > to -stable and then fix any problems which arise. Yes please :) That's what the -pre's are for.. to suss out the bugs by the advertursome and intelligent users before releasing to the masses. ---------------------------------------------------------------------- Comment By: Richard Archer (richardarcher) Date: 2002-07-03 16:46 Message: Logged In: YES user_id=279311 I did a lot of work on some of the db classes (MySQL, OCI8, ODBC come to mind). But I don't have most of those other databases running to test with. I think you'll find most of my work is in the devel tree only. I wasn't willing to commit untested code to the -stable tree. For example, the odbc driver in devel has *heaps* of improvements and bug fixes. It even implements lock(). While I did have an ODBC datasource at the time, I wasn't willing to commit a 500 line patch to -stable based on my development testing alone. Maybe we should just bite the bullet and commit this stuff to -stable and then fix any problems which arise. ---------------------------------------------------------------------- Comment By: Chris Johnson (chaska) Date: 2002-07-03 16:05 Message: Logged In: YES user_id=279065 I thought one of our fearless programmers had gone through the db_* classes and made them more uniform? Or was a I dreaming? ..chris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885 |
|
From: <no...@so...> - 2002-07-04 12:26:17
|
Bugs item #561019, was opened at 2002-05-27 10:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885 Category: DB_SQL Group: current CVS Status: Open Resolution: None Priority: 5 Submitted By: Marco Pratesi (pratesi) Assigned to: Nobody/Anonymous (nobody) Summary: db_pgsql.inc: lock() causes a warning Initial Comment: With the PostgreSQL class, the following code causes a warning: $qid = new DB_Sql(); $qid->lock("tablename"); The warning is: Warning: Supplied argument is not a valid PostgreSQL link resource... This is due to the fact that in this case the constructor issues an empty query, that causes a "return 0" without issuing "$this-connect()". When lock() is requested, the following line is executed: $result = pg_Exec($this->Link_ID, "lock table $table"); but $this->Link_ID is not a valid link, as connect() has not been executed yet. The problem could be solved using $this->query() instead of pg_Exec(), in analogy to what is done in db_mysql.inc, as in the following: $result = $this->query("lock table $table"); ---------------------------------------------------------------------- >Comment By: Marco Pratesi (pratesi) Date: 2002-07-04 12:26 Message: Logged In: YES user_id=65709 I agree. I am working on the new development branch of PgMarket and I could be useful just with testing the MySQL and PgSQL classes. I am using the MySQL class taken from 7.4pre1, but, if that class is too much outdated w.r.t. the CVS, my tests are not as much useful as they could be. I am also using the PgSQL class (and I develop mainly using PostgreSQL rather than MySQL); to solve some problems I have switched to a CVS snapshot of the PgSQL class + some changes made by me, that fix some minor problems: function unlock() { - return pg_Exec($this->Link_ID, "commit"); + return $this->query("commit"); } I have made this change for coherence with the lock() method, where I have also eliminated an "else" to simplify the code: function lock($table, $mode = "write") { if ($mode == "write") { - $result = pg_Exec($this->Link_ID, "lock table $table"); - } else { - $result = 1; + return $this->query("lock table $table"); } - return $result; + return 1; } Moreover, I have made the following changes to avoid the possibility of warnings with error_reporting = E_ALL : function f($Name) { - return $this->Record[$Name]; + if (isset($this->Record[$Name])) { + return $this->Record[$Name]; + } } function p($Name) { - print $this->Record[$Name]; + if (isset($this->Record[$Name])) { + print $this->Record[$Name]; + } } BTW, if I can be helpful for the PHPLib classes I am using, I am happy to help. I am also developing some new PHP classes that are compatible also with PHP3 and that I release under the GNU LGPL. Bye, Marco Pratesi ---------------------------------------------------------------------- Comment By: Chris Johnson (chaska) Date: 2002-07-03 22:15 Message: Logged In: YES user_id=279065 I say go for it. I think getting a packaged pre-release out the door is more important at this point in time than trying to scare up the people and resources to do that kind of coverage testing. ..chris ---------------------------------------------------------------------- Comment By: nathan hruby (nhruby) Date: 2002-07-03 21:56 Message: Logged In: YES user_id=19736 > Maybe we should just bite the bullet and commit this stuff > to -stable and then fix any problems which arise. Yes please :) That's what the -pre's are for.. to suss out the bugs by the advertursome and intelligent users before releasing to the masses. ---------------------------------------------------------------------- Comment By: Richard Archer (richardarcher) Date: 2002-07-03 21:46 Message: Logged In: YES user_id=279311 I did a lot of work on some of the db classes (MySQL, OCI8, ODBC come to mind). But I don't have most of those other databases running to test with. I think you'll find most of my work is in the devel tree only. I wasn't willing to commit untested code to the -stable tree. For example, the odbc driver in devel has *heaps* of improvements and bug fixes. It even implements lock(). While I did have an ODBC datasource at the time, I wasn't willing to commit a 500 line patch to -stable based on my development testing alone. Maybe we should just bite the bullet and commit this stuff to -stable and then fix any problems which arise. ---------------------------------------------------------------------- Comment By: Chris Johnson (chaska) Date: 2002-07-03 21:05 Message: Logged In: YES user_id=279065 I thought one of our fearless programmers had gone through the db_* classes and made them more uniform? Or was a I dreaming? ..chris ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=403611&aid=561019&group_id=31885 |
