Well, I'm disappointed again by John Lim's continual lack of a decent bug report; claiming that you lack the time while having had time to post two blog entries about it is pretty poor.
Let's see the code you're using to call into PDO, John; there's not much time before we release, and without your cooperation, the problems you're seeing won't get addressed.
I'll speculate that John's ADOdb snippet:
<?php $rs = $db->Execute("select * from table where a=? and b=?",array('a'=>1,'b'=>2)); ?>
is trying to bind 'a' and 'b' by parameter names, but the parameters in his query are identified only by their positions (using question marks). I wonder how that is supposed to work? Maybe he should try this:
<?php $rs = $db->Execute("select * from table where a=:a and b=:b",array('a'=>1,'b'=>2)); ?>
It's also worth noting (again) that PDOStatement::getColumnMeta is intentionally unimplemented on this first PDO release, hence its experimental status; in other words, don't use it. Most people don't need this kind of feature anyway.
Wez Furlong in
PHP.
Shame on you.
You already understand the issue John is having. You state it not once, but twice in your post criticizing him.
He uses bind by ?, instead of parameter names. PDO doesn't support them yet (because of your experimental status).
Both of his posts describe that exact behavior, and specifically state that its "probably due to their experimental status".
Criticizing someone for providing a clear and well-written bug report is bad enough. But then telling him to change his behavior when you plan to implement that exact behavior later is a great way to ensure you won't get bug reports.
I've seen plenty of complaining about the php team's quick-to-bogus status for bugs, but when you stretch that arrogance out to someones blog post?
You've really taken the cake. For shame.
Stop being so defensive, and just implement the getColumnMeta already.
It's not a bug report if it's not in the bugs database (http://bugs.php.net). And PDO is not the first thing (http://phplens.com/phpeverywhere/?q=node/view/214) that John whines about before understanding the underlying issues.
I suggest that anyone else that thinks that either named or positional parameters don't work in PDO take a few minutes and go and read the various publications, conference slides and even (gasp!) the PHP manual, and hey, maybe even try it, before they suggest otherwise.
I've yet to see a clear written bug report from John, so I'm merely stating that in my blog. Without a clear bug report we have to guess what John is doing, or otherwise develop psyhic abilities.
Wez Furlong in
Comment.
I have been playing around and using PDO on and off since it first came out. It provides more functionality and protection then the original mysql library ever did in most cases.
As to bugs, Ever email I have sent to phpdev mailing list ( asking good questions instead of spending my time whining on some blog ) has been answered in a prompt and polite manner.
The php developers have set methods and ways to report issues and whining on a blog is not one of them.
Let's not shoot the messenger here... Wez is making a very valid point without being judgemental, so I see no need to attack him. The mere fact that he has to guess at the problem because no proper bug report was filed is an indication of time being wasted because of poor communication.
Okay I get that there are many ways of doing things, even in the code base which I maintain I use authoritative arrays and having some code to do some magic to generate the SQL minus requiring a bindparam ala Oracle Style.
Generally it's easier to blog about an issue than it is to post a bug report. ;)
When I'm blessed with some "PHP time", I don't go trawling through the internet to find problems that people are complaining about on their blogs. I also don't sit and meditate, hoping to pick up problems from the psychic aether. No, I sit down and check the PHP and PECL bug databases. Sometimes I'll even search my heavily laden inbox (I get a lot of mail) if I manage to remember that someone emailed me about a problem.
I lead a busy life; my memory is mostly dedicated to things that are really really important to me, and that doesn't tend to include stuff in my mailbox or blogs. Anything else that I want to get done goes into some kind of tracker or calendar.
Filing bug reports is important a number of reasons:
- so it won't be forgotten
- so that others can find the issue
- so that we can associate a patch with the problem as part of our QA process.
The first two are particularly important for me. It can easily be a couple of weeks before I get time to sit down and deal with a bug report. If it's come in via email and I've been really busy, it will likely be forgotten, so I suggest that the reporter file it properly. Having it in the bug tracker not only allows other people to find the problem, but also allows the other developers to be made aware of it, and possibly even fix it.
The last point is part of our quality assurance; our general rule is to only allow bug fixes on the stable branches. Ideally, each commit will have a bug number associated with it, and will be noted in the NEWS file. You can then look it up in the bug db to find out additional information about it.
So, while I understand being lazy (it's soo convenient), I also know that without the help of people that are running into problems, those problems won't get resolved, and that is really what my blog post was all about.
There's no substitute for being thorough; a half-assed bug report is usually a good indicator that the reporter hasn't taken the time to read the manual, and thus that the problem is really their fault. Logically, you can extend this back to blogging about problems; if the reporter hasn't even made it as far as the bug tracker, then the outlook is not so good.
So, lazy is fine, and blogging about your problems is also fine, provided that you don't expect anything to be done about it. In OpenSource if you want something fixed, you need contribute to the process.
Wez Furlong in
Comment.
In OpenSource if you want something fixed, you need contribute to the process
So true....
there may be an element of truth to it.
For instance I really wish it were possible on the PHP Manual add comments, to also submit bugs or ask questions instead of just being able to add comments.
If all three things were tied into the manual pages then it would also help for the people reading the manual as they could not only see comments, but also questions and answers, and bug or feature requests all relating to that particular manual page.
As it currently stands, people need to to search in three different locations to find or add comments, bugs and Q&A that all related to the one manual page and as a result they'd rather just open up their blog and complain about it all in the one place.
I would have submitted this as a feature request, but I didn't see that ability on the add-notes page, which is what the features relates to. =D
The ability to add related notes to manual pages is a great feature, I just don't see why it was limited to notes.
BTW. Thanks Wez, for all the work you have put into making PHP better and cute dog you have there. She looks very similar to my Kelpie X.
I agree with you Wez. The very act of submitting a bug report acknowledges the fact that you are part of a community which requires the bug to be fixed. By blogging about it, you make that bug yours.
It's a case of "I want it fixed" versus "This should be fixed." Personally, I think the former is quite rude.