So in short, +1 RTBC! :-) Thanks, Dmitri! If you're doing that, you're an idiot and there's no reason for us to support it. The only place this would break is if you serialize a connection object, change your database configuration in settings.php to have a different DB (or really, DB type) connected to a given key/target pair, and then unserialize the connection. In hindsight having key and target be separate methods may or may not make sense but that's not something to play with at this point, especially since nothing outside the DB layer is playing with these anyway. Technically, this does introduce new public methods on the connection object which may be considered a functionality change, but they're necessary to fix this bug and are, really, useless anywhere else so I consider them DB-layer internal. :-)Īrguably we could wait to grab those keys until _sleep() instead of doing so in the constructor, but the performance difference should be undetectable. This is a great use of _sleep() and _wakeup().

Then on wakeup, grab that connection singleton back based on those values. The solution here uses PHP's serialization magic methods to break that last connection from $select to $conn when serializing and instead store the connection key and target, which as they're just strings serialize just fine. So when you try to cache the theme variables, that works its way down the line to the connection object and explodes, which is exactly what the PHP engine says it should do. PDO cannot be serialized, since it contains a resource. The connection object is an instance of DatabaseConnection, which extends PDO. The $select object references the connection object to which it is bound. If using a DB backend for Views, that $views_query object references a SelectQuery object, $select. The $view object references its own $views_query object. One of those theme variables is a $view object, exposed to the theme layer to give themers more stuff to play with. The cache system is trying to cache theme variables. So for those playing our home game, here's what's going on here: This was the first thing that I did after running apt-get update apt-get upgrade. I have caching enabled, including page, block, views, and css/js aggregation. I updated MySQL to the latest version a few minutes before this happened, but I think that this is a bug in PHP PDO, not MySQL.

Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies This is the output of php -v: PHP 5.3.2-1ubuntu4.5 with Suhosin-Patch (cli) (built: 13:41:55) When I checked the watchdog table, I copied this line from Sequel Pro: 217Ē php %type: !message in %function (line %line of %file). When I saved a poll in a D7 b3 site created by Aegir on Ubuntu Server 10.04, I got an error shown in the attached screenshot.

Pdo file