[Update: Beta 3 is out; please report any/all bugs via http://bugs.php.net]
With the impending release of PHP 5.1b3, it's a good time to mention the status of PDO. We've had an excellent round of QA since beta 2, resulting in the following notable items:
- common core test suite to ensure individual driver conformance
- MySQL and PostgreSQL drivers now support native prepared statements and bound parameters (when available), for improved performance.
- OCI and ODBC drivers have been improved.
- PDOStatement::closeCursor() method has been added, to explicitly free up a database connection if you're done with a result set before you reach the end.
- Added $db->getAttribute(PDO_ATTR_DRIVER_NAME) to tell you which driver is in use (mostly useful for people writing layers over the top of PDO).
- Enabled the unix build of PDO_DBLIB, which provides access to Sybase/MSSQL servers via freetds. This driver is not as mature as the others, so feedback is especially welcomed. If you're running on windows, you'll probably have a better experience using PDO_ODBC to talk to SQL Server.
- There are no unresolved bugs (a couple of feature requests, but no bugs)
How many people are seriously using Win9x with PHP?
There are quite a few APIs that are either server-only or Win2k and up that PHP would benefit from using. Before we just go ahead and use them (breaking support for Win9x) I thought it would be a good idea to find out how many people this will affect.
So, if you use, or know of someone that uses PHP on Win95, Win98 or WinME, please add a comment here, explaining why, so we can guage how much of an impact bumping the version requirements for PHP would have.
I've had a number of people ask me about this feature recently, and now it's here. What took so long? I just didn't have mysql 4.1 installed anywhere, or enough time to set aside to look into it. A patch from Guy Harrison (for multiple rowsets) caught me at just the right time today, and set me up for some hacking.
In CVS (and showing up on snaps soon), the pdo_mysql driver now has support for the following features when compiled against mysql 4.1 or higher:
- Support for queries returning multiple rowsets, via PDOStatement::nextRowset().
- Supports "native" sqlstate error codes, for "better" error reporting.
- Supports native prepared statements and bound parameters.
I'm looking for feedback on these changes; even if you have an older mysql installation, please try the snapshot, as I want to ensure that it continues to build and work fine there (should be fine, but there's nothing better than physically confirming it).
Any problems, then hop along to http://bugs.php.net/ and file a bug report; thanks!
(PS: installing mysql 4.1 on a gentoo box when you only have a 56k modem takes a while)
Why won't it let you do it??
Am I the only person that gets forwarded email (as an attachment) and that needs to reply to the original sender?
It seems to me that someone went out of their way to prevent you from doing it; well, slap their wrists!
I'm about to depart for the UK for the Inbox Outbox conference. I'm leaving a little early so that I can fit in some family and friends time over the weekends and some other business either side of the conference itself.
Normally, I would say something about having choppy internet access, but given that I have none at home right now, whatever I'll have will be better than nothing. I hope. :)
Well, if you haven't tried it already, and you're interested in PDO, don't: just grab the latest snapshot from snaps instead.
Lack of communication, and perhaps some politics, meant that 5.1beta shipped with a stupid bug in the PDO core extension, causing a infinite loop on request shutdown.
I'm somewhat annoyed at this, because it's a showstopper that we could and should have caught before announcing the beta.
Oh well, such is life.
I'm just getting stuck into packing things up ready to move into our first home in the USA (we've been living in an apartment for a few months), so I'm not going to let it bother me.
Have a good weekend.
As Zak kindly reminds us, it is the eve of PHP's tenth birthday. My first involvement with PHP was as an alternative to ASP for a client in Japan; they wanted a dynamic web site, but it had to run on their Solaris servers. At that time, PHP 4 was still in beta, but already felt superior to ASP. As that project grew, I felt that it would be cool if I could use fsockopen() to talk to a credit card payment processor.
In September of 2000 I came up with a crude patch that got SSL to work with fsockopen(). I went on to refine this patch (a great deal!) and wound up implementing the Streams layer.
I've always been surprised and impressed at how easily my contributions were accepted by the PHP project, especially because the patch to enable streams was so wide-ranging (it touched pretty much every file in the source tree), and even more so because I'd never previously met anyone from the PHP project, either in real life or even just "around" online.
Getting involved with PHP has had a profound effect on my life; being invited to speak at conferences in Holland, Germany, USA, the Carribean, Toronto and more recently in Mexico has been a hell of an experience. And I mustn't forget that I wouldn't be working here with George Schlossnagle at OmniTI, on a different continent from where I was born, if it wasn't for PHP.
I owe the majority of my salary over the last few years to PHP, and so I want to send my thanks to Rasmus for getting the ball rolling, keeping it rolling, and pimping my name when I was looking for work. I'd also like to extend my thanks to Christine; based on the reactions of my own wife (Juliette) to some of the PHP things I've done (and that's nothing compared to Rasmus), I have some idea of how much effort you must have put out over the years. Thanks to you both!
Long live PHP :-)
PS: thanks to everyone that has contributed to the PHP project over the years.
I've just finished chatting with Marcus Whitney for part of the next installment of his Pro PHP Podcast show. It's my first recorded conversation/interview for public consumption. I'm kinda nervous and hope that I didn't ramble on too much. But that's what it's all about; getting more personality out of people than you would with just text alone.
As ever, technology has a wicked sense of humour, so there are probably going to be a couple of stops-and-starts (perhaps more if I really rambled on and Marcus has to edit ;-). Oh yeah, I might come across as sounding more like Barry White than I would normally.
I'm looking forward to seeing how the show develops--listening rather than reading is not just a refreshing change but also something you can do while working on other things.
The next installment of the show should hit the 'net in the next couple of days.
Just a quick response to Lukas' blog entry.
I know Lukas would love to see things work a little differently in PDO, but there are good technical reasons why things are the way they are now. Here are some reasons in random order:
- It's impossible to build a magic database abstraction layer that works for everything
- PDO is data-access abstraction (not database abstraction). The primary goal is to make things similar enough that you don't end up cursing at the API. The abstraction is also present for the benefit of extension developers, making it less of a headache to build database drivers for PHP.
- No two underlying database client APIs are the same
- Most don't separate the concept of a prepared statement handle from a result set.
- Most overload functions like RowCount() to have the dual meaning that Lukas mentioned.
- the MySQL client API is a bad example of a typical database client API. Don't use it as your baseline for comparisons to the others.
A closing comment regarding the naming of the PDO methods; I didn't follow Lukas' "Unofficial subjectively observed key design principles"; the PDO APi just happens to follow the APIs of the underlying database clients because it means that PDO doesn't have to do too much work on top of those APIs, and because those particular APIs have been designed by people that live and breathe databases. I like to avoid the NIH (Not Invented Here) syndrome where I can (although I confess that I do succumb to it from time to time). Regarding the length of the method names, I don't believe that they should be as short as possible, but don't believe inOverlyLongNamesForTheSakeOfMakingTheCodeReadLikeEnglish().