Skip to content

2006

more PDO PECL releases

PHP 5.1.3 was just released, including the latest PDO and PDO drivers. If you're still running older releases of PHP you should probably upgrade. If you don't want to upgrade the PHP core then you'll be pleased to know that I've also released the PHP 5.1.3 versions of PDO, PDO::MYSQL, PDO::PGSQL, PDO::SQLITE and PDO::ODBC to PECL--these are the versions that I've had time to personally test.

These are identical to the code in PHP 5.1.3, with the exception of PDO::ODBC, which includes two additional bug fixes that didn't make it in time.

Enjoy!

On a related note, I noticed that people were downloading PHP 5.1.2 and then trying to build older PDO drivers from PECL into it, and then filing bugs when it didn't work. Don't do that; it really doesn't make sense. As a general rule, PHP 5.1 and higher bundle PDO, so if the version of PHP you are using is newer than the latest PECL package, stick with the version of PDO that ships with PHP. If the PECL package is newer, then go for that instead.

  • in Blog
  • 1 min read

A kick in the nuts

Flurong!?. I thought RSS was supposed to help avoid things like mis-spelling the names of the people you're syndicating. Double-nut-pain is scored for making the same typo twice. Ouch. :)

I know that phpdeveloper.org produced by human hands, and I'm not knocking the summaries at all; it would just be nice to have at least our names correctly spelled, in case they are re-syndicated from there and the typo propogated around the 'net.

  • in php
  • 2 min read

Undefined behaviour

or, why I find the Solaris manual pages amusing.

In this thread on the php internals list, Kevin is asking why the handling of whitespace in certain PDO DSNs is inconsistent. I go on to point out that the manual doesn't say anything about whitespace in DSNs, and that all the documented examples have no whitespace around the DSN parameters.

His response was: 

   but in this example we have a space and it works
   mysql: host = localhost; dbname=test

And another that I got via private email: 

   But it doesn't tell me I should avoid spaces either.

This is an example of undefined behaviour. The PHP manual doesn't define what happens when you put whitespace in there. That doesn't tell you anything at all about whether you should or should not do that. It might work now, and it might work next week. In 6 months time, when you application is widely deployed and someone changes an apparently unrelated part of their system, it might NOT work and might result in someone getting paged at 3am trying to figure out what the mysterious problem is.

If you take a look at the Solaris manual pages you'll see evidence that the folks at Sun have run into people reporting problems with undefined behaviour. My favourite so far is in one of the pthread manual pages where it describes in one short paragraph what a particular function does, and then proceeds to describe a very large number of use cases that are undefined, along the lines of: 

   If you do X, then the behaviour is undefined.
   If you do Y, then the behaviour is undefined.
   If you do Z, then the behaviour is undefined.

and so on for a couple of pages. This is an example of really good documentation; it only really needs to tell you how to use it, and assuming that people read the manual and follow the examples, they shouldn't run into problems. Explicitly stating what constitutes undefined behaviour is a sign that the documentor has good technical understanding of the routine and, almost certainly, too much past experience with tracking down problem reports from people that are misusing the API.

While really good documentation for everything would be nice to have, it's not always available. In circumstances where the documentation doesn't tell you about what happens when you do a particular thing, you should treat it as though the documentation says "If you do FOO, then the behaviour is undefined". If you need to find out a definitive answer, contact the author/vendor and ask them. When they give you an answer, listen to them. They've said what they've said for a reason.

PDO::MySQL slides from MySQLUC 2006

I tried to upload my slides from the conference, but run into problems with a firewall somewhere, so they've had to wait for me to return home.

So, here we are: Using MySQL with PDO (PDF).

This was my first MySQL users conference, and it seemed to go well. Truth be told, I'm not a database fanatic (which is ironic considering my involvement with PDO), so I didn't find a lot of the material to my taste. I did learn a few things from Jim Winsteads embedded mysql talk (something I bet he'll be surprised to hear :) and also Hartmut Holzgraefe's mysqli talk. I also got to chat to Monty about the issues I mentioned and meet some new faces, including my Evil sysadmin, some old and some older faces (Hi Sterling :)

The conference was quite big; 1500 attendees, 6 tech tracks (there were a couple of other non-tech tracks too, but I forget exactly what they covered) and a lot of BOF sessions. If MySQL is your bread and butter, you might want to consider attending the next one.

  • in php
  • 1 min read

Using PDO::MYSQL ?

I've recently discovered a few things about how the mysql client library does things that seem a bit silly to me, so I'm going to share them with you.

  • native prepared statements cannot take advantage of the query cache, resulting in lower performance.
  • native prepared statements cannot execute certains types of queries, like "SHOW TABLES"
  • native prepared statements don't correctly communicate column lengths for certain other "SHOW" queries, resulting in garbled results.
  • calling stored procedures multiple times using native prepared statements causes the connection to drop.

I recommend that you use the following attribute when working with PDO::MYSQL, available in the current PHP 5.1.3 release candidates and snapshots: 

$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, true);

This causes the PDO native query parser to be used instead of the native prepared statements APIs in the mysql client, and effectively eliminates those problems.

I'll admit that the last point could well be a bug in my code; since I'll be at the MySQL Users Conference next week, I should be able to sit down with the right people and fix it.

  • in Blog
  • 1 min read

Test-driving Google calendar

Well, I guess I feel similarly to JWZ when it comes to calendar software. Yesterday I downloaded the Lightning 0.1 extension for Thunderbird. It's a partial improvement over running Sunbird; it's handy to be able to view the calendar right there in thunderbird, but it clearly needs a lot more polish before it can be really used.

I was all set to switch over to Lightning from Thunderbird, but then I read JWZ's entry that mentioned Google Calendar at the bottom, and it looks good.

The major points that appeal to me:

  • SMS notifications prior to events. You don't have to be at your desk to get the reminder, or even to have your computer turned on.
  • It's online, accessible from anywhere that's connected to the 'net
  • Public events can be published as RSS and iCal (find mine in the geeky sidebar to the right)
  • The whole thing (including private events) can also be published as RSS and iCal
  • You can import existing calendar data from iCal and CSV files
  • UI is nice

So, I think I'll be using google calendar to manage my calendar. I still need to be able to see the private OmniTI calendars, so I'm still using Thunderbird/Lightning to do that.

  • in php
  • 1 min read

Upcoming conference appearances

I'll be giving my "usual" PDO talk at both MySQL Users Conference 2006 and OSCON 2006 (the MySQLUC version of the talk will have a MySQL focus).

If you're interested in PDO and haven't had the opportunity to see me give this talk yet, please consider trying to get to one of these conferences. My talk covers the design decisions behind PDO, suggests some best practices for using it, highlights portability concerns (particularly because PHP programmers have been "dummied down" by the older mysql client library API) and more.

As usual, I'm always open for questions during the talk (I'm there for your benefit after all) and I try to make myself more generally available during the conference, so if you want to ask me questions, or even just have a chat, then feel free to approach me.

Solaris libumem port on SourceForge

I've had an incredibly busy year so far, having spent the better part of half of it on-site with a customer/partner across the atlantic, and it's only March. In addition to working with them on a large scale deployment proof-of-concept project (I'll blog more about that when I'm sure it's ok to blog about it), we've been hard at work on our Ecelerity 2.1 release, which is just about out-the-door (just some final QA to go).

One of the internals features in our new release is the adoption of the Solaris slab memory allocator, libumem. We already had our own slab allocator, but there are some interesting innovations in libumem that reduce lock contention and cache invalidations that make it attractive for a very high performance multi-threaded application like Ecelerity.

Since Solaris is OpenSourced under the CDDL, we were able to incorporate the allocator into Ecelerity and port it to Linux and Windows and not be forced to open-up our entire source-code. The CDDL requires that we publish the code that we modified, so we set up a project on SourceForge. The code isn't out-of-the-box usable just yet, as it lacks its own configure script and makefile, but it won't take much effort to create those.

Thanks Sun for opening up such good quality code under a commercial software friendly license!

http://sourceforge.net/projects/umem/

  • in php
  • 1 min read

Happy New Year, and by the way, we think you don't do shit

I have to say that I'm disgusted at the attitude of two of our prominent PHP developers.

PHP is a volunteer project guys. If you don't like the fact that I lead a very busy professional life then that's your problem.

I know how many hours I've spent developing PHP and maintaining its systems over the last year. (Guess who gets paged when our mail systems run into problems?)

Getting snarky because I'm on vacation for a week is just plain wrong. Really.

PS: if you think that attitude will motivate me into doing more for PHP you're wrong. It just makes me want to go and do anything else instead.