June 2008 Archives

Somewhere in the process of doing something or other in the last few weeks, I managed to break my installation of MySQL on my MacBook Pro. I can't remember now how I managed to break it, but I had shoved a note onto my "to do" list to fix it.

After downloading and installing the latest stable version of MySQL (5.0.51b), I discovered that Perl could no longer access the database. I figured I just needed to recompile DBD::mysql against the new MySQL libraries. But when I tried, I got complaints similar to this one:

Can't use dbi_imp_data of wrong size (127 not 124) at /System/Library/Perl/Extras/5.8.8/darwin-thread-multi-2level/DBI.pm line 1190.

It seems I did two things wrong. First, I downloaded the "Mac OS X 10.5 (x86_64)" version of the MySQL server. Apparently, although Leopard (OSX 10.5) is supposed to be 64-bit, the included Perl 5.8.8 is compiled as 32-bit. So for compatibility, I scrapped MySQL and re-downloaded the 32-bit version. Of course, I may be mistaken about this, because...

I still got the errors! Some more searching suggested that some bug fixes in DBI for FreeBSD might be related. I was using the pre-installed DBI 1.52, and that was error number two. So I upgraded to the latest DBI (1.605), make realclean, and tried again.

I got a warning when running Makefile.PL:

Multiple copies of Driver.xst found in: /Library/Perl/5.8.8/darwin-thread-multi-2level/auto/DBI/ /System/Library/Perl/Extras/5.8.8/darwin-thread-multi-2level/auto/DBI/ /Library/Perl/5.8.6/darwin-thread-multi-2level/auto/DBI/ at Makefile.PL line 759

It seems to be detecting both the original Apple version of this file, and the new one I just installed from CPAN. However, I was still able to build the software, so apparently this is a pickled herring or whatever you call those things that look scary but don't actually matter.

Whew! Now we're back up and running. I'm tempted to try the 64-bit version again to see if it will work now that I have updated DBI, but that's too much like work, and since I only need it for testing, it isn't very important.

The moral to the story? Erm ... Don't break stuff? I'm not sure, but anyway, if my experience helps you get your MySQL working faster, I'll be happy.

Recently I read a note called DBIx::Class Gotchas over at Perl Alchemy. I've been struggling myself for several months with a bundle of old Class::DBI code, and I can relate. Both packages fall into the category of Object-Relational Mapping (ORM), software that tries to map programming objects around entities stored in a relational database.

For a long time I was a huge proponent of ORM software, and I still am for certain types of projects. But the honeymoon is over for me, as I've started to hit some of those limitations they always warn you about. ORM buys you a big gain in productivity, because the software reduces database access patterns from a dozen lines of code to just one or two. If you need to get a small project up and running fast, ORM is a tool that can help a great deal.

The trouble with ORM is that your objects don't always map directly to the queries you want to make. To simplify the thorny problem of SQL generation, often the underlying implementation is doing things in Perl code that would be more efficiently done in the database, or executing multiple SQL queries when a single join would have done the trick. When your project gets very large, very complex, or very dependent on database performance, the ORM layer suddenly seems to hinder as much as it helps. I now spend as much of my time coding around the ORM layer as using it.

Still, without ORM I would spend a lot more time writing "select * from table" queries and the like, and I almost always have the need to optimize for development time rather than execution time. So I have this love/hate relationship.

What's your experience with ORM software? Love it? Hate it? Tolerate it?