Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.11.5

Bug #17554 Err in update when primary key = 0
Submitted: 2010-07-03 02:47 UTC
From: jacek Assigned: alan_k
Status: Closed Package: DB_DataObject (version 1.9.4)
PHP Version: 5.2.10 OS: Linux fedora 11
Roadmaps: (Not assigned)    
Subscription  


 [2010-07-03 02:47 UTC] jacek (Jacek Pawlowski)
Description: ------------ update doesn't work when primary key value is 0 (zero). it works when primary key value is not zero Test script: --------------- $x = new DataObjects_GLOBAL; $x -> get(0); $x -> COMMENT = date("Y-m-d H:i:s"); $x -> update(); the table: CREATE TABLE `GLOBAL` ( `id` int(11) unsigned NOT NULL, `COMMENT` varchar(16) COLLATE latin1_general_ci NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_general_ci Expected result: ---------------- COMMENT should be updated with current date-time Actual result: -------------- err: DataObjects_GLOBAL2 : ERROR : update: trying to perform an update without the key set, and argument to update is not DB_DATAOBJECT_WHEREADD_ONLY

Comments

 [2010-07-05 08:02 UTC] alan_k (Alan Knowles)
-Status: Open +Status: Feedback
have you tried ->update(DB_DATAOBJECT_WHEREADD_ONLY)
 [2010-07-05 08:03 UTC] alan_k (Alan Knowles)
$x = new DataObjects_GLOBAL; << always use factory!!! $x->whereAdd('1=1'); // update all columns? $x -> COMMENT = date("Y-m-d H:i:s"); $x -> update(DB_DATAOBJECT_WHEREADD_ONLY);
 [2010-07-05 22:13 UTC] jacek (Jacek Pawlowski)
I tried: $x = new DataObjects_GLOBAL; $x -> whereAdd('id=0'); $x -> COMMENT = date("Y-m-d H:i:s"); $x -> update(DB_DATAOBJECT_WHEREADD_ONLY); works. and as per request: $x = new DataObjects_GLOBAL; << always use factory!!! $x->whereAdd('1=1'); // update all columns? $x -> COMMENT = date("Y-m-d H:i:s"); $x -> update(DB_DATAOBJECT_WHEREADD_ONLY); all rows have been updated.
 [2010-07-06 04:29 UTC] alan_k (Alan Knowles)
-Status: Feedback +Status: Bogus
Sorry, but your problem does not imply a bug in PEAR itself. For a list of more appropriate places to ask for help using PEAR, please visit http://pear.php.net/support/ as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PEAR. Please check the manual next time http://pear.php.net/manual/en/package.database.db-dataobject.db- dataobject.update.php Regards Alan
 [2010-07-06 05:05 UTC] jacek (Jacek Pawlowski)
this works (from documentation): $person = new DataObjects_Person; $person->get(12); $person->name='fred'; $person->update(); and it doesn't $person = new DataObjects_Person; $person->get(0); $person->name='fred'; $person->update(); and this is not an bug?
 [2010-07-06 07:03 UTC] alan_k (Alan Knowles)
No, it's expected behavior, update() either works a) with keys defined - update() will work b) using WHERE_ADD_ONLY It will not work the way you are trying to make it, since it has no idea what to base the update rule on.
 [2010-07-06 10:36 UTC] jacek (Jacek Pawlowski)
last comment: the table has two rows: 0, 'john' 1, 'joe' column 1 (with values 0,1) is the primary key and the update works when I say get(1) but it doesn't when I say get(0) - only difference is that value of the primary key - both integers 0 and 1 - and value 0 give me the record (the record is read) but cannot be updated. You have the record so why do you need the rule and it works with primary key value != 0. I don't see anything in documentation saying that I can't use ->get(0) if zero is valid value for primary key. For me any non negative integer (unsigned int) is a valid primary key - if this is the designed behaviour then the doc should be updated warning users about this behaviour. I spent some time tracking this and I discovered that changing primary key value changes behaviour of the script. There is nothing in SQL saying that I can't have primary key = 0. Also I did the same test using Python with SQLAlchemy and it is no problem. It is frustrating discovering different design goals between different languages. To be honest for me SQLALchemy it is expected behaviour. Thanks for the explanation.
 [2010-07-06 10:56 UTC] alan_k (Alan Knowles)
Can you run it in debug mode and find out what is happening. DB_DataObject::debugLevel(5); should give you an indication. Regards Alan
 [2010-07-06 11:02 UTC] alan_k (Alan Knowles)
-Status: Bogus +Status: Open
Can you try modifying line 1321 if (empty($this->{$keys[0]}) && $dataObject !== true) { to if (!isset($this->{$keys[0]}) && $dataObject !== true) {
 [2010-07-06 23:31 UTC] jacek (Jacek Pawlowski)
I made the change: to: if (!isset($this->{$keys[0]}) && $dataObject !== true) { from: #if (empty($this->{$keys[0]}) && $dataObject !== true) { and now it works as I expect. I guess function empty should not be use here, it evaluates to true for integer = 0. I guess it is bug after all.
 [2010-07-07 07:20 UTC] alan_k (Alan Knowles)
-Status: Open +Status: Closed -Assigned To: +Assigned To: alan_k
This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. Thanks for your persistence on this. Regards Alan