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

Bug #2979 0 as primary key may cause unwanted insert
Submitted: 2004-12-16 18:54 UTC
From: m_c_ at gmx dot net Assigned: justinpatrin
Status: Closed Package: DB_DataObject_FormBuilder
PHP Version: 4.3.8 OS: Windows
Roadmaps: (Not assigned)    
Comments Add Comment Add patch

Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem : 37 + 47 = ?

 [2004-12-16 18:54 UTC] m_c_ at gmx dot net
Description: ------------ Hey, i'm sorry i don't have a lot of time to describe in detail what's wrong... Just in a few words: As far as I know, in the form procession, formbuilder decides whether to use an insert or update statement by determining if the primary key is set or not. In my application i just run over this problem: when editing a record with primary key set to 0, there happens an insert into the database, although it should actually be an update. Hope that helps... Christof


 [2004-12-16 19:11 UTC] justinpatrin
Hmmmm, sure enough this happens because we're checking to see if the primary key is empty or null. Normal sequences and auto_increment PKs start at 1. I'd suggest for now making your PK not allowed to be anything which empty() returns as true. Markus: Why exactly are we using empty() here? Perhaps we should change this if to this instead: if (!isset($this->_do->$pk) || strlen($this->_do->$pk) == 0) { I've never found empty() to be all that's basically the same as if (!$var).
 [2004-12-21 19:13 UTC] justinpatrin
Markus? AFAIK this is a negligible BC break and shouldn't break anything.
 [2004-12-28 11:39 UTC] mw21st
empty($var) and if (!$var) definitely are *not* the same, as empty also checks for the existence of a variable or array key prior to evaluating it, thus avoiding warnings thrown by PHP if it hasn't been defined yet. On the other hand, I never encountered primary keys starting at 0, so the problem never occured to me. I guess it's safe to switch to the proposed combination of isset() and strlen().
 [2005-01-02 00:13 UTC] justinpatrin
This bug has been fixed in CVS. In case this was a documentation problem, the fix will show up at the end of next Sunday (CET) on In case this was a website problem, the change will show up on the website in short time. Thank you for the report, and for helping us make PEAR better. I've switched to isset() and strlen() the various pieces of code which were using empty(), including the one that sets the insert.