Reserved keyword

So i have been banging my head over this issue for way to long today. And had to find out the hard way it was a simple little thing as usual. But Doctrine (version 1 if anybody asks) didn’t offer me any good info with the error message it was displaying. Nor did PHP or MySQL (should be MariaDB if you ask me).

While working on a very heavy Doctrine based project. I ran into a at first glance weird error. Yesterday i created a class structure. All good and well. The class i was working on was called Shows. But it represented a single Show entity and therefore should have been called Show. So i decided to do a rename action. Pretty complex because of different dependencies. But after a few tries i got it right. Except Doctrine was failing with a syntax error. After a code inspection i still couldn’t spot the issue. The only thing i didn’t do yet was output the query and run it from a shell. And this failed with the same syntax error message. Damn!

INNER JOIN show s ON …

Checked the whole query. Still couldn’t spot the issue. Then for some weird reason i decided to escape the table name with backticks `Show`. Everything worked again. Wow! So Doctrine doesn’t escape table names. But why did it fail in the first place? By now i had the feeling i was using a reserved keyword. And a check confirmed this. An error would have been helpful here. I had a bit of luck though. As it turned out the table should have been named different anyway. I made a small workaround for it in my code. But decided that was not the way to go So the lesson of the day for me was don’t use reserved words for class / table names. A good thread on the issue can be found here.

APC object corruption

The second issue to bite my ass was a nice one as well. And this time no indication of an error at all. While working on the same classes discusses shortly above. I renamed the class names and the file names on disk. And after a page reload in the browser. The framework was complaining it couldn’t load the changed class. I checked the class and file names and all were correct. After toying with it for 20 minutes i decided to ask my colleague. And he suggested to restart Apache. for the second time today i was stumped. Everything worked again. Turns out that APC couldn’t find the already in memory loaded class. After renaming the corresponding filename (seems logical now that i think of it). A restart of Apache flushed the APC cache and therefore the issue. This sounds like a bug though. And requires some further inspection or a bug report. We will see.

PHP Fatal error

Last week while setting up PHPUnit i ran into a weird issue while testing PHPUnit from a shell on my local desktop. The whole test suite would run from start to end. But at the end would display the following not so descriptive error message.

PHP Fatal error: Exception thrown without a stack frame in Unknown on line 0

This kept me busy for some hours. This happened somewhere in a large framework. And there was no clear sign of what was causing the issue. Some googling did reveal some cases in which this error may occur.

There was an exception while handling an exception
There was an exception while running a destructor
There was an exception while closing the session
There was an exception while running a shutdown function
There was an exception while running a autoload function

The issue in my case was the fact that the configuration file wasn’t loaded yet. And therefore the log file location was not set correctly. Logging in this framework is done in a plugin system which is pretty cool. We can basically assign plugins for certain log levels (and more). This was the FileLogger. This all still does not explain why it failed with this particular error message. But a bit of digging in the Log/Plugin system revealed the issue.

register_shutdown_function(array(__CLASS__, 'Shutdown'));

Message are stored in a queue and written to file in a register shutdown function. Which was failing because the logfile location was not set correctly. This was causing an exception to be thrown inside the registered shutdown function. And therefore triggering this horrible error message. Be careful with register_shutdown functions.

So that made me think about last week. I think it was on Friday. but there was some up stirring about MySQL (Oracle) asking a license fee for using the InnoDB storage engine. And quite a big fee if you ask me :) This really sucks. I love the InnoDB engine. What would we do without it…? That’s where MariaDB comes into play. It uses the XtraDB storage engine which is basically InnoDB on steroids. XtraDB is developed and maintained by Percona. Some really smart MySQL guys :) At the moment it’s under the GPL license. And i can only hope it will be freely available for a long time.

So i went ahead and took a look at how hard / easy it is to change MySQL for MariaDB. I tried this on a Debian Lenny machine which made the process quite easy i have to mention.

First get the PGP key from the server and import the repository locations. After that hit update to refresh the local database.

$ wget -O- http://ourdelta.org/deb/ourdelta.gpg | sudo apt-key add -
$ cd /etc/apt/sources.list.d; wget http://mirror.ourdelta.org/deb/sources/lenny-mariadb-ourdelta.list
$ aptitude update

As we can see we have some new packages

Get:8 http://mirror.ourdelta.org lenny/mariadb-ourdelta Sources [864B]
Current status: 3 updates [+3], 232 new [+11].

Searching for ‘mariadb’ gives the following packages

$ aptitude search mariadb

p libmariadbclient-dev – MariaDB database development files
p libmariadbclient16 – MariaDB database client library
v libmariadbclient16-dev – MariaDB embedded database development files
p mariadb-client – MariaDB database client (metapackage depending on the latest version)
p mariadb-client-5.1 – MariaDB database client binaries
p mariadb-client-core-5.1 – MariaDB database core client binaries
v mariadb-common
p mariadb-server – MariaDB database server (metapackage depending on the latest version)
p mariadb-server-5.1 – MariaDB database server binaries
p mariadb-test – MariaDB database regression test suite (metapackage depending on the latest version)
p mariadb-test-5.1 – MariaDB database regression test suite

So let’s go ahead and install the server and see what happens.

$ aptitude install mariadb-server

Some mysql files get removed the mysql-common package gets updated and the new MariaDB packages get installed.

The following NEW packages will be installed:
libmariadbclient16{a}
libmysqlclient16{a}
mariadb-client-5.1{a}
mariadb-client-core-5.1{a}
mariadb-server
mariadb-server-5.1{a}

The following packages will be REMOVED:
mysql-client-5.0{a}
mysql-server{a}
mysql-server-5.0{a}

The following packages will be upgraded:
mysql-common

Now that’s done. Let’s check MySQL’s output

$ mysql –version
mysql Ver 14.16 Distrib 5.1.49-MariaDB, for debian-linux-gnu (i486) using readline 5.1

Just as i expected. Nothing really changed here. The whole MySQL API is till available for calling. Only the base system is now replaced by MariaDB. So let’s see what storage engines are available.

$ mysql -uroot -p

MariaDB [(none)]> show engines;
BLACKHOLE /dev/null storage engine (anything you write to it disappears)
MRG_MYISAM Collection of identical MyISAM tables
FEDERATED FederatedX pluggable storage engine
MARIA Crash-safe tables with MyISAM heritage
CSV CSV storage engine
MEMORY Hash based, stored in memory, useful for temporary tables
ARCHIVE Archive storage engine
MyISAM Default engine as of MySQL 3.23 with great performance
InnoDB Supports transactions, row-level locking, and foreign keys
PBXT High performance, multi-versioning transactional engine

And because the MySQL APi is still in tact. From PHP we can keep using the mysql and mysqli interfaces. This is great stuff!

I’m working on a small ZF project which uses the MVC structure. And in the Initializer the database connection is setup like this:

public function initDb()
    {
    	$pdoParams = array(
            PDO::MYSQL_ATTR_USE_BUFFERED_QUERY => true
        );

        $params = array(
            'host'     => 'localhost',
            'username' => '***********',
            'password' => '***********',
            'dbname'   => '***********',
            'driver_options' => $pdoParams,
        );

        $db = Zend_Db::factory('Pdo_Mysql', $params);
        Zend_Db_Table_Abstract::setDefaultAdapter($db);
        Zend_Registry::set('DB', $db);
    }

So when i first instantiated a connection to the database i was presented a nice error on screen. The stack trace is quiet long. But this is the most relevant part.

exception ‘Zend_Db_Adapter_Exception’ with message ‘SQLSTATE[HY000] [2002] Can’t connect to local MySQL server through socket ‘/tmp/mysql.sock’ (2)’

The php bug tracker revealed a nice solution. For some strange reason the PDO extension can’t determine the correct socket while the mysql, mysqli extensions can. This is easily solved in the bootstrap of the project by adding an extra parameter to the config array passed when calling Zend_Db::factory();

$params = array(
            'host'     => 'localhost',
            'username' => '***********',
            'password' => '***********',
            'dbname'   => '***********',
            'driver_options' => $pdoParams,
            'unix_socket' => '/var/run/mysqld/mysqld.sock'
        );

        $db = Zend_Db::factory('Pdo_Mysql', $params);
        Zend_Db_Table_Abstract::setDefaultAdapter($db);
        Zend_Registry::set('DB', $db);

Jun 21 17:43:02 ims1 dovecot: auth-worker(default): mysql: Connect failed to localhost (mail): Access denied for user ‘mail_admin’@'localhost’ (using password: YES) – waiting for 1 seconds before retry

It took me a while to figure this out. The settings in ‘dovecot-sql.conf’ were correct. Logging in with the same data from a shell went without a problem. I remembered i had this problem some years ago. With a vpopmail setup. The problem then was the encryption algorithm used by MySQL. So i tried to use the older encryption algorithm.

SET PASSWORD FOR ‘user’@'localhost’ = OLD_PASSWORD(‘password’);

After a restart everything was fine.

Jun 21 18:41:03 ims1 dovecot: auth-worker(default): mysql: Connected to localhost (mail)

Like i said it took me a while to figure out. So maybe i can safe somebody some time.

Paypal:
http://tinyurl.com/6rxjsz
Or
by check payable to:

MySQL, Inc.
Mail to: MySQL, Inc.
Attn: Linda Dong
20450 Stevens Creek Blvd #350
Cupertino, CA 95014

or
US wire transfer:

MySQL Inc: 7396643001
SWIFT: NDEAUS3N

or
International wire transfer in any currency:
Bank: Nordea Bank
Bank address: Stockholm, Sweden
Bank account: 3259 17 03868
IBAN: SE27 3000 0000 0325 9170 3868
SWIFT: NDEASESS

Some years ago this problem was obvious. The problem was always solved by copying the libmysql.dll to windows/system32. But this changed. For the last year i never had to copy this file. So i couldn’t really believe this was the problem. But after trying for some hours. I gave up. Copied the libmysql.dll file to windows/system32. And voila…. the mysql extension now loads. But i still have no solution for the pgsql extension. Which i really need by the way. WTF happened here? How is it possible that two of the most used extensions do not load after a clean install?

UPDATE*

The postgres problem is solvable by installing the postgres server. And adding the PostgreSQL\8.3\bin to the PATH variable. Weird stuff…