ID: 40417 User updated by: exaton at free dot fr Reported By: exaton at free dot fr Status: Open Bug Type: PDO related Operating System: Windows XP Pro SP2 PHP Version: 5.2.1 New Comment:
@ xing : I had not seen that word from Wez, but indeed is does make sense to add the check in principle -- the API should make sure that enough tokens were bound (to enhance its service and avoid "silent" bugs) and can also guarantee that not too many were bound (might as well). It's back to the problem with bindno, however... I'm not even sure of the name of that variable. I think it would stand for "number of bindings", e.g. the expected number of bound variables or values. I believe that's how Ilia read it, and quite reasonably so. That meaning is just not valid in the special (but probably not uncommon) case of multiple named tokens (as opposed to question marks ?) with the same name. Just a shot in the dark : wouldn't a workable, albeit expensive, solution be to create a little hash table here with the names of all the named tokens ? It would not hold duplicates, by definition ; hence named tokens with the same name would only be counted once. Therefore zend_hash_num_elements(params) would just have to be compared to zend_hash_num_elements(token_names). But of course question-mark placeholders would have to be treated in a different way... Anyway, I don't think that's anything the PHP developers won't have thought about themselves. Just my 2 cents. Previous Comments: ------------------------------------------------------------------------ [2007-03-01 08:15:50] xing at mac dot com I have to agree with exaton on this. This is an absolute "app-breaker" change and MUST be noted in the change-log at the very least. It is pure luck I found this change before my official upgrade to 5.2.1. I really hope there there a solution to this. On a blog, wez mentioned that this was a fix and the previous ability to bind one to many placements was rather an bug. I however, strongly disagree on a simple level that the pre-5.2.1 pdo binding just "made sense". Why should php force developers to introduce more lines of code that does nothing more when this can be take care of behind the scenes? ------------------------------------------------------------------------ [2007-02-27 13:00:47] exaton at free dot fr Hi again, thanks for reopening this issue. Sorry for being so snarky before, but I'd just received a little dressing down from my boss because of having to add the workaround to already-validated code at extremely short notice. Classic case of pushing for an upgrade on the production server in the frenzy of the moment. I'll let you guys take care of this now. I've kept my test case around so I'm available for further trials if I can be of any use. ------------------------------------------------------------------------ [2007-02-27 11:50:41] [EMAIL PROTECTED] This is really annoying issue, which forces me to rewrite some of the code I've done in the past. Perhaps the bindno shouldn't be incremented if the named placeholder already exists in the placeholders struct? Would it break something else? ------------------------------------------------------------------------ [2007-02-24 08:47:52] exaton at free dot fr Wow. I'm flabbergasted. Mr Alshanetsky, I am, as they say, and until further notice, disappointed in you. No update of the CVS code. Not even a note in the manual to reflect this spec change. I guess this is going to have to wait until someone else reports it. It's got to be relatively common, especially in not too complex search engine implementations. Until then, therefore... ------------------------------------------------------------------------ [2007-02-24 03:19:49] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php . ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/40417 -- Edit this bug report at http://bugs.php.net/?id=40417&edit=1
