Recently while working at my new job at Hydra Studio, my buddy Rob and I came across an issue that was killing us:
“Invalid parameter number: no parameters were bound”
When people used our search feature on our site, a few specific search terms would result in un-caught exceptions. Of course, this ONLY happened on the client’s server. Nothing like saying a project is solid, only to find out there’s something ‘special’ about the production environment.
The first thing we did, was to list out what was unique about the client’s server. The client was using a Media Temple box running CentOS 5.2. For the un-initiated, CentOS is the free version of Red Hat Enterprise Server. We run Macs in the office, and our staging server is a Mac too. Other than the OS, the normal ‘LAMP’ stuff pretty much matched verbatim.
So, we started digging into the differences between the compiled versions of PHP between the development and production environments, and one thing popped out at us:
PCRE
The version that’s supported on Red Hat / CentOS is 6.6. That’s horrible. 6.6 came out nearly 3 years ago, and the version the client was running had no support for unicode at all. A little research, and we found out that Zend Search Lucene (what we built the search functionality on top of) requires unicode for the way it stores search indexes.
With that, we figured we were done. The client had a limitation on their server, they needed to address it, and the problem would fix itself when they did. Not quite so fast …
I was testing some of the searching on my iMac, when the same issue happened on my own computer. Disaster! Could it be that something in our own code was the culprit? What half-reproducible error was causing this?
After hours of searching for an answer on the googlez, I came across some help on the Zend Issue Tracker. It turns out, that PDO was failing when it was trying to prepare a statement, when that statement contained a question mark. When I switched my SQL adapter to Mysqli, the problem was solved. Both the production and the development environments were bug free after the change.
It turns out, that our search indexes would return fields that either contained question marks, because they actually existed in the document (as was the case locally), or because the document had encoding errors when the search index was built (as was the case on the production servers). The ORM we used would grab the documents, and grab relevant data from the database by querying with the fields stored in the index.
The SQL that was being prepared, would then look something like this:
‘SELECT id FROM folks WHERE first_name LIKE ‘Jo?hnny’
The question marks would be interpreted by PDO as variable markers, which rightfully didn’t exist.
So, the real solution wound up being a little bit of a mix between the client’s problem, and our own. Granted, we needed to catch question marks being stored in db before they got there. That improves the longevity of our own code. However, the search functionality will still return results that may have question marks in them, thus causing the same issue. That issue is resolved by using Mysqli, but that feels more like a hack, than a solution.
Anyways, I spent a long time trying to search the answer to this and found nothing except the one mention in the issue tracker. For those of you using Zend Lucence Search on Red Hat / CentOS servers. Make sure you use Mysql if you’re using the Zend ORM to populate models based on results returned from the index.
Oh yeah, and make sure you filter your input too, Mr. Bobby Tables…..
Pingback: Unemployed | Cory Collier