I just pushed up a new Drizzle branch at lp:~fallenpegasus/drizzle/newplugins

It contains two new plugin types, one for configuration interface, and one for query cache. Those two are not "plumbed in", and are in fact just templates, containing two dummy entry points with two dummy parameters. But they follow the evolving pattern for plugin types.

It also contains fixes and improvements for the logging and errmsg plugins. The logging engine implementation has parameters for filtering for slow queries and for "big queries", both ones that return a lot of rows, and ones that just examine a lot of rows.

It's all also been internationalized.

There is still lots of work to be done, but it's fun to get this foundation stuff going.

I just read that Toru has a branch he's been working on a query cache plugin interface as well, so we need to work together to stitch all our work …

It’s like removing the brakes from your car. yes, it will go faster (slightly less weight) but, dude, you just removed the brakes.

The errmsg plugin interface is almost done.

The next plugin interface will be fairly more fraught, but useful. Making the configuration interface as a plugin.

This means that instead of keeping the configuration in the /etc/my.cnf and/or /etc/drizzle.cnf, the configuration variables could be kept in the Gnome registry, or in LDAP, or via lookups in some online configuration database server.

This would make managing and configuring huge arrays of Drizzle servers much much easier.

A while back, Giuseppe pointed out Andrey Zhakov’s implementation of Virtual Columns for MySQL.

Since then, Andrey has ported that code to Drizzle and sent us a message about the Launchpad Tree.

First, the bad news. I waited long enough to actually look at it that the merge was no longer clean. The Drizzle codebase moves pretty quickly, you know. Andrey was wonderful about helping fix those issues, I got it all merged in and tested, and pushed.

Drizzle now has Virtual Columns. w00t.

As a quick aside, I’d like to mention a few things Andrey …

So many engines, and so little to choose from. This is one of our two major decision points in Drizzle right now.

Let me explain.

Today we have Innodb, Maria, Falcon, and PBXT.

Simple?

Not really. Innodb is not a single engine, it is three engines. We have the default one which is shipped. It has been the wunderkinder for years now but has been showing its age. Go buy a piece of hardware that has four cores and it quickly becomes apparent that it is not aging well. There is the Innodb plugin, and while it delivers on features, performance still …

So, I installed one of those math question anti-spam plugins for WordPress comments. It stopped the spam! Unfortunately it also stopped all valid comments when the answer was right, although it did work when I first set it up. So if you tried leaving a comment (I see a few were denied) for one of the recent Drizzle or MySQL related posts (like the New libdrizzle), please try again. :)

Anyone have a suggestion for a good anti-spam plugin for WordPress comments? I’ve looked a bit but nothing really stands out.

What’s the new libdrizzle? It’s a complete rewrite of the client library for the Drizzle project, but it also has full support for the current MySQL protocol (4.1+). Right now Drizzle uses the same protocol as MySQL, but work is being done to design a new, more robust protocol. Even when the Drizzle protocol changes, I plan to keep full support for the MySQL protocol since there is a need for a good low-level non-blocking client library. Also, once libdrizzle turns into a full protocol library (server and client packets) it could make for some interesting Drizzle/MySQL hybrid proxies.

Over the weekend I made a lot of progress on the new library, and last night I just finished up the first pass at the core functionality. It can now do full query and result processing. Currently only non-cached results are being used (no store_result() function), but the cached interfaces will be …

MySQL, and thus currently Drizzle, logs stuff to it's error log. "Stuff" being errors, warnings, and info messages. Inside the code, they ultimately get sent to stderr, which is directed to whatever file is specified by the "log-error" option. It's all in the MySQL documentation at http://dev.mysql.com/doc/refman/6.0/en/error-log.html

I'm changing that in Drizzle, replacing the error logging stuff with a plugin interface.

The first implementation will, just like the current builtin system, write to a file, or to stderr. I expect soon after, plugins that send the messages to syslog, as SNMP traps, and to a CSV table, will be written.

Just like the query logging work, getting this going will shink the drizzle core even more, and likely remove still more unneeded locks.

Is anyone out there actually still using 32-bit systems for new deployments? On purpose?

I know I occasionally see people who have 64-bit systems and have installed 32-bit OS on them. They are one of two things: people who don’t know what they are doing, or why their server is then having memory problems, or people who have 32-bit Linux installed on their laptops because there is no good 64-bit Flash Player plugin for Linux. (/me shoots Adobe in the Face… it’s called re-compile it and release, please)

The 32-bit laptop people I don’t care about - they are not yet hosting websites on their laptops while browsing YouTube. Yet.

The others just need the learning.

Which brings me back to… should we start to consider 32-bit a dinosaur sort of like AIX 4.1?

(I should be clear here… I am honestly asking… not just trolling. I’m also not advocating bad code - see previous …

I haven’t been doing any new features or exciting things like Query Logging on Drizzle, although I have to say that I’m very much looking forward to logging to syslog. What I have been up to is continuing the seemingly never ending battle to clean up things in the code. Some of the changes are essentially style issues, but some of them additionally help to uncover potential problems. Take my most recent nemesis, ulong.

There are multiple problems with ulong. The first is that it’s non-standard. If you want your code to be portable at all, you have to do something like this in a header file.
#if !defined(HAVE_ULONG) && !defined(__USE_MISC)
typedef unsigned long ulong; /* Short for unsigned long */
#endif
Now, of course, there’s nothing fundamentally wrong with …