Lenz Grimmer's blog

There has been a lot of buzz about the MySQL 5.5 GA release and its new features and other user-visible improvements. In this blog post, I'd like to touch on a less noticeable, but still important change.

CMake has already been used to build the MySQL Server on Windows for a long time, while the GNU autotools were used on all other platforms. Since MySQL 5.5, all builds on all platforms are now performed using the same tool chain. With the latest release of MySQL 5.5, we've made an important step to clean up and simplify the MySQL build system: the support for autoconf/automake has now been removed completely. We've been performing the release builds of MySQL 5.5 using CMake exclusively for quite some time already. It became obvious that maintaining two separate build systems simply had become too much of a burden for our engineers, especially since the autotools-based builds were no longer exhaustively tested. This change was outlined in WorkLog#5665 - Removal of the autotools-based build system. We've made this step in close cooperation with our community of packagers (e.g. the maintainers of MySQL packages on the various Linux distributions).

By moving to CMake, we are giving our developers one common build mechanism for all platforms and there is a lot of new useful functionality such as out-of-source builds or a GUI for configuring the build options. And they can now build MySQL in the very same way that we do it for our own binaries! I've covered the advantages in my previous blog post about Building MySQL Server with CMake on Linux/Unix already. We've also created a general article about CMake and MySQL as well as an Autotools to CMake Transition Guide on the MySQL Forge Wiki. The description of the source build process in the reference manual has also been updated to reflect this change.

A big “thank you” should to go to Vladislav Vaintroub and Davi Arnaut for implementing and pushing the transition to CMake forward, and to Paul DuBois for creating and improving the documentation! Wearing my former build and release engineer hat, I am very happy about this change.

Other CMake-related articles that are worth reading:

• Giuseppe Maxia: Building MySQL 5.5 with CMake
• Jonathan Perkin: How To Build MySQL Releases
• Santo Leto: Step by Step Guide on How to Compile MySQL 5.5 on Microsoft Windows

I recently received a question from Robin Schumacher at Calpont, the makers of the InfiniDB analytics database engine for MySQL: "How would you recommend we try and get bundled in with the various Linux distros?"

Since this question has come up several times before, I thought it might make sense to blog about my take on this.

First of all, please note that there is a difference between "being part of the core distribution" and "being available from a distributor's package repository". The latter one is relatively easy, the former can be hard, as you need to convince the distributor that your application is worth devoting engineering resources to maintain and support your application as part of their product. It's also a space issue – distributions need to make sure that the core packages still fit on the installation media (e.g. CD-ROMs or a DVD). Therefore they take a very close look at each package and if it's really needed to be part of the installation medium or if it's fine to provide it for download from a package repository instead.

Distributors prefer to keep their core product small and restricted to the "basic OS building blocks". While MySQL might still be considered to be a part of this, this probably does not apply to the various plugins and extensions that are available for it. Therefore the best approach is to invest some engineering time and start doing the packaging yourself, either by hiring an engineer capable of creating and maintaining the packages, or by finding someone in your community who has the required experiences and is willing to do it.

While it's of course possible to set up and maintain your own build and package hosting infrastructure for that, I recommend to make use of the existing services provided by the distributors.

The top tier distributors all provide means of offloading the maintenance of "non-core" packages to their community, offering various options for packages to be made available. For example, Novell/openSUSE provide the free "Build Service", which is capable of building packages for other distributions as well (e.g. Fedora, Mandriva, Debian/Ubuntu, etc.). In addition to automating the builds, the Build Service also takes care of the distribution via their download mirror network and ensures that your application can be found via their package search interface.

Red Hat/Fedora provide something similar, named "Koji" – but it's "Fedora only". Here's a HOWTO that outlines the process of becoming a Fedora package maintainer.

Ubuntu/Canonical have "Personal Package Archives (PPAs) – if your project is hosted on Launchpad already, that might be something to look into for providing Debian/Ubuntu packages. Alternatively you could join the Debian project and start building and maintaining your package there. They maintain a list of "Work-Needing and Prospective Packages", a description of the process on how to become a new maintainer is outlined here.

If you'd like to target Solaris/OpenSolaris as well, there is the OpenSolaris Source Juicer – a web service which allows OpenSolaris community developers to build packages (using RPM spec files) and publish them for review, so they will be included in an official package repository. The Software Porters Community Group coordinates, advocates, encourages and helps with the porting of Software from multiple Platforms to the OpenSolaris Platform.

CMake is a cross-platform, open-source build system, maintained by Kitware, Inc.

From the CMake.org home page:

CMake is a family of tools designed to build, test and package software. CMake is used to control the software compilation process using simple platform and compiler independent configuration files. CMake generates native makefiles and workspaces that can be used in the compiler environment of your choice.

It has been used for building the MySQL Server on Windows since MySQL 5.0 – the initial CMake build support was added in August 2006.

For building MySQL on all other platforms, the GNU autotools (autoconf, automake and libtool) are currently being used.

CMake is used in some other MySQL projects as well, e.g.

• MySQL Connector/C
• MySQL Connector/C++
• MySQL Proxy

On February 22nd, Vladislav Vaintroub pushed the changes required to implement WorkLog#5161 "CMake-based unified build system" into the "mysql-next-mr" branch (aka the "Celosia" mile stone).

From this version on, CMake can also be used to build MySQL on Linux and other Unix platforms. For the time being, the autoconf/automake files are still available as well, but will be phased out once the CMake build enviroment has reached the desired level of maturity. The change was announced on February 28th on our "internals" developer discussion list.

The purpose of WL#5161 is to simplify the MySQL build system. It is much easier and less error-prone to maintain a unified build system for all platforms than two separate ones.

CMake has been chosen because of several reasons; the worklog description lists a few pro-CMake arguments (slightly rephrased):

• CMake works on Windows. The GNU buildsystem does not really work and likely never will work natively on Windows (Using Cygwin is not really an option).
• Traditionally, new MySQL features that required changes in the build environment (e.g. the plugin system, unit tests, most recently googletest integration) were always implemented on Unix first, leaving Windows behind (sometimes for years). This would not happen with a unified build system.
• MySQL already uses CMake since 2006 on Windows, so we do not need to start from scratch, only port what we have to Unix.
• CMake runs on every OS and compiler we support.
• It is simple to obtain and install on a wide range of platforms. It is available in all major Linux package repositories (e.g. Ubuntu, Fedora, OpenSUSE). It is also in the OpenSolaris repository, known as SUNWCmake. It's in FreeBSD ports and available for Mac OS X. It is also very simple to compile it from source, the single prerequisite is a working C++ compiler and make utility.
• CMake has support for features we need and might need, e.g. system checks or cross-compiling.
• CMake provides integrated support for packaging. It can handle both simple packages (tar.gz or zip archives) and more complex things like DEB and RPM without much extra coding.
• Good integration with the popular IDEs (Visual Studio, Xcode, Eclipse CDT, KDevelop). Developing in an IDE makes the development process more enjoyable, and potentially it lowers the barrier for external contributors. Of course, CMake can generate traditional Unix Makefiles, which appear to be are superior to the ones generated by GNU autotools (for example, they have progress indicators, colored output and working dependencies).
• The scripting language used by CMake is simpler than m4 used by autotools.
• CMake is a single small tool, not a bunch of different tools as in GNU system (autoconf, autoheader, automake, libtool)

I'd like to mention a few additional reasons:

• Out-of-source builds – CMake can separate the build directory from the source directory. This is convenient, as your working source tree is not cluttered with object files and other fragments of the build process.
• Build configuration using a GUI. The cmake-gui package (based on Nokia/TrollTech's Qt library) provides a convenient way of enabling and configuring the various available build options. This is much better than having to memorize all the required defines and configuration flags.
• Integrated support for creating a wide range of package formats.

The CMake Wiki lists a number of other "nice to have" features.

From a developer perspective, I hope that it will make it much easier to finally implement two things that many developers working with MySQL have been waiting for (now that the build code has been cleaned up):

• Compiling the embedded MySQL Server (libmysqld) as a shared library
• Better support for cross-compilation

Building MySQL with CMake is quite simple and straighforward – the process is outlined on the MySQL Forge Wiki. The document is still work in progress and we'd like to encourage you to take a look at it, try to follow the steps and update/improve the Wiki page, if needed! Your feedback on the build process is appreciated. Feel free to join our internals mailing list to discuss your impressions and observations or submit a bug report via the Bug Database. It's likely that the build still has a few rough edges that we'd like to fix quickly (e.g. BUG#51502 – a fix for this one is already commited to the mysql-next-mr-bugfixing source tree and will be merged into the mysql-next-mr trunk soon).

If you're new to CMake, you might want to take a look at the "Getting Started With CMake (An End-User's Perspective) For Cross-Platform Building" screencast or the "Running CMake" article.

Happy hacking!

So you're a small startup company, ready to go live with your product, which you intend to distribute under an Open Source License. Congratulations, you made a wise decision! Your developers have been hacking away frantically, getting the code in good shape for the initial launch. Now it's time to look into what else needs to be built and setup, so you're ready to welcome the first members of your new community and to ensure they are coming back!

Keep the following saying in mind, which especially holds true in the Open Source world: "You never get a second chance to make a first impression!". While the most important thing is of course to have a compelling and useful product, this blog post is an attempt to highlight some other aspects about community building and providing the adequate infrastructure. This insight is based on my own experiences and my observations from talking with many people involved in OSS startups and projects.

I admit it — I'm a fan of simulation software, particularly flight simulators. Probably the best Open Source Flight Simulator out there is FlightGear — it provides an impressive level of reality and you can download and install many additional plane models and terrains. There are packages of FlightGear 1.0.0 in the games repository of the openSUSE Build Service, which works quite well and I have been enjoying it a lot. However, the FlightGear project released version 1.9.x quite a while ago (1.9.1 was published in January 2009) and I was itching on giving the new version a try (just take a look at the screenshots and you know what I mean). However, building FlighGear on Linux is quite a complex task with many dependencies, and so held off from doing it myself, waiting for someone else to perform the update...

Well, this weekend I finally bit the bullet and did it myself - FlightGear 1.9.1 has now been added to my home:LenzGr build repository. I based my packages on the ones included in the games repository, but I plan on cleaning them up a bit and splitting them into separate packages (currently the FlightGear source RPM contains SimGear and fgrun as well). I also "borrowed" the OpenSceneGraph sources and spec file from the PackMan repository, in order to have a functional build. Unfortunately FlightGear currently only builds on a very limited list of distributions so far (namely OpenSUSE 11.0, just what I needed) — I haven't had time to adapt the spec files for FlightGear and OpenSceneGraph to match the appropriate build dependencies for the other distributions yet and "02-check-gcc-output" gives me some grief on platforms where it actually builds but generates compiler warnings (but patches are welcome!)...

Oracle/InnoBase announced the availability of the embedded version of InnoDB at this year's MySQL Conference & Expo, but I have not seen a lot of comments or reviews about it so far. Which surprises me, because I think this is a very interesting piece of technology!

In my opinion it might actually hit the sweet spot for application developers seeking an alternative embedded database solution. SQLite is nice and popular, but it seems to have concurrency issues when used in multi-threaded applications. An embedded MySQL server would be an alternative - this is what the Amarok developers decided to go with, for example. But this approach has its issues, too, especially the lack of a shared library version of libmysqld poses some challenges when distributing binaries.

This is where I think the embedded version of InnoDB might have an edge. It's pretty lightweight in comparison to a full-blown MySQL server, provides excellent crash-recovery (which is essential for desktop applications), transactions (useful in environments with high concurrency) and foreign key constraints. I'm not sure how important these are for embedded use cases, it probably depends on the complexity of the data to be stored. On the downside, Embedded InnoDB does not "speak" SQL. In order to store and retrieve values, you need to use the InnoDB API. See the chapter Concepts and Architecture for more details and an overview.

Another possible reason for the low popularity might be that it's currently not part of any Linux distribution (yet) and that Oracle only provides binary tarball packages for Linux and a Windows binary for download from the web site.

Therefore I've now created a spec file to build RPMs of Embedded InnoDB and added it to my repository on the openSUSE Build Service, which now provides Embedded InnoDB packages for a wide range of RPM-based Linux distributions. I hope that the spec file will be included in the next source distribution. I've posted it (and a patch to fix a few problems with the examples) to the newly created InnoDB mailing list, but to be sure I added a note to the Embedded InnoDB Forum as well.

In case you are processing and working with geospatial data on MySQL, you may be interested in the following UDF (plugin) for MySQL 5.1: Koji Okumura from Oki Labs Japan has ported two functions from PostGIS into a MySQL UDF:

• distance_sphere(point, point): Returns linear distance in meters between two lat/lon points. Uses a spherical earth and radius of 6370986 meters. Faster than distance_spheroid(), but less accurate. Only implemented for points
• distance_spheroid(point, point, spheroid): Returns linear distance between two lat/lon points given a particular spheroid. Currently only implemented for points.

Since it's an UDF, it can be easily added to an already installed server. These two functions actually complement the improved precise GIS functions nicely (which provide a 2-dimensional DISTANCE() function).

You can download the UDF source tarball from here. Compiling it is pretty straightforward and requires a local copy of the MySQL 5.1 sources and the ususal build environment. For my testing, I used the 5.1 source tree that includes the additional precise geospatial functions. Below I just list the commands required to build and create the binary tarball and omit the lengthy output in between some of these commands:

$ bzr branch lp:~mysql/mysql-server/mysql-5.1-wl1326
$ cd mysql-5.1-wl1326
$ BUILD/compile-pentium-max
$ make bin-dist

You should now have a binary tarball mysql-5.1.26-rc-linux-i686.tar.gz that you can install or deploy by using the MySQL Sandbox, which I used for my further testing:

$ tar zxvf mysql-5.1.26-rc-linux-i686.tar.gz -C ~/opt/mysql
$ cd ~/opt/mysql
$ mv mysql-5.1.26-rc-linux-i686 5.1.26
$ make_sandbox 5.1.26
$ cd ~/sandboxes/msb_5_1_26
$ ./use
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 4
Server version: 5.1.26-rc Source distribution

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql [localhost] {msandbox} ((none)) >

Success! Let's see if the new GIS functions work:

mysql [localhost] {msandbox} ((none)) > SELECT DISTANCE (GEOMFROMTEXT('POINT(0 0)'),GEOMFROMTEXT('POINT(1000 1000)')) AS distance;
+-----------------+
| distance        |
+-----------------+
| 1414.2135623731 |
+-----------------+
1 row in set (0.00 sec)

Now let's compile and install the UDF that provides the new spherical distance functions. Download the sources and extract the tarball in the same directory in which you branched the MySQL server sources:

$ tar zxvf mysql-udf-distance_spheroid-1.0.tar.gz
$ cp distance_spheroid/*.{cc,h} mysql-5.1-wl1326/sql
$ cd !$
$ g++ -DMYSQL_SERVER -shared -o udf_distance_spheroid.so -I../regex -I../sql -I../include spatial.cc calc_distance_spheroid.cc udf_distance_spheroid.cc

This will build the shared object udf_distance_spheroid.so that you now have to copy into the plugins directory of your server:

$ install -D udf_distance_spheroid.so ~/opt/mysql/5.1.26/lib/mysql/plugin

Now we have to load the UDF and make the new functions known to the server. Get back into your sandbox or fire up the commandline client again:

mysql [localhost] {msandbox} ((none)) > CREATE FUNCTION distance_sphere RETURNS REAL SONAME "udf_distance_spheroid.so";
mysql [localhost] {msandbox} ((none)) > CREATE FUNCTION distance_spheroid RETURNS REAL SONAME "udf_distance_spheroid.so";

Now you're ready to experiment with these new functions! For my test case, I calculated the distance between Hamburg, Germany (where I currently live) and Heidelberg, Germany (where I grew up) by providing the Lat/Lon coordinates as points:

mysql [localhost] {msandbox} ((none)) > SELECT DISTANCE_SPHERE(GEOMFROMTEXT('POINT(53.583333 9.983333)'),GEOMFROMTEXT('POINT(49.412222 8.71)')) AS 'Distance (m)';
+-------------------+
| Distance (m)      |
+-------------------+
| 479037.4799112912 |
+-------------------+
1 row in set (0.00 sec)
mysql [localhost] {msandbox} ((none)) > SELECT DISTANCE_SPHEROID(GEOMFROMTEXT('POINT(53.583333 9.983333)'),GEOMFROMTEXT('POINT(49.412222 8.71)'),'SPHEROID["GRS_1980",6378137,298.257222101]') AS 'Distance (m)';
+-------------------+
| Distance (m)      |
+-------------------+
| 479345.1884839106 |
+-------------------+
1 row in set (0.00 sec)

Interestingly, using the virtual ruler on Google Earth gave me a distance of 471881.44 meters for the same coordinates. Not sure where the difference comes from, I assume they are using a slighly different projection system? It would be interesting to see, if these results match what you would get out of PostGIS using the same queries.

In any case, these two functions may come in handy, if your application needs to calculate distances between two points on a map. So give it a try! If you have tested this functionality and want to give feedback to Koji, please reply to his post on the MySQL GIS Forum.

I recently added two new packages to my repository on the openSUSE Build Service:

• Maatkit is a collection of essential command-line utilities for MySQL. Each is completely stand-alone, without dependencies other than core Perl and the DBI drivers needed to connect to MySQL, and doesn't need to be "installed" - you can just execute the scripts. This makes the tools easy to use on systems where you can't install anything extra, such as customer sites or ISPs.
• protobuf - Protocol Buffers - Google's data interchange format. Protocol Buffers are a way of encoding structured data in an efficient yet extensible format. Google uses Protocol Buffers for almost all of its internal RPC protocols and file formats.

The protobuf package is required, if you want to compile drizzle. Packages are available for openSUSE, Fedora and Mandriva Linux. Feedback is welcome!

For those of you who enjoy running exotic operating systems: I just stumbled over a port of MySQL 5.0.45 for OS/2 and eComStation. Thanks a lot to Paul Smedley for maintaining this version! He also maintains a large number of other Unix applications that he ported over to OS/2 - very impressive.

Just came off today's MySQL University session about How to Build MySQL on Windows - Reggie did a great job on explaining how to build the MySQL Server from Source on Windows using the Microsoft development toolchain and some additional required tools. I am glad to hear that we're making progress on making it easier for Windows developers to work with the source code and Reggie and the other members of our Windows Task Force (what a nice acronym this one makes!) have plenty of other ideas for improving that experience.

If you missed his session, the audio file and IRC log will be published from the MySQL University pages shortly.

And in case you haven't heard about MySQL University before, check out the pages on the MySQL Forge and take a look at the upcoming schedule! Next week, Jan is going to give an introduction to the MySQL Proxy, which will to be an interesting session for sure. Did I mention that attending MySQL University is free and everybody is welcome to join? All you need is an IRC client to post questions and discuss the topic and an application capable of playing OGG audio streams for listening to the presenter. The MySQL Forge Wiki has detailed instructions on how to get going. See you next week!

As I felt the itch to do some quick hacking yesterday, I decided to provide an RPM spec file for the MySQL proxy. The changes have been commited to the SVN trunk now and I added some hints to the INSTALL file on how to perform an RPM build.

Here is a quick summary of how to convert the current SVN code into an installable RPM. You build environment needs to fulfill a few additional prerequisites (a gcc compiler and the C library header files are taken for granted here), I added the versions I used on my openSUSE 10.2 system for reference:

• autoconf 2.56 or newer (autoconf-2.60)
• automake 1.9 or newer (automake-1.9.6)
• MySQL 5.0.x include files (MySQL-devel-5.0.41)
• pkg-config (pkgconfig-0.20)
• libevent 1.x or newer (libevent-1.1)
• lua 5.1 or newer (lua-5.1.1)
• glib2 2.4.0 or newer (glib2-2.12.4)

The following steps need to be performed:

# Check out the trunk of the SVN repository
$ svn co http://svn.mysql.com/svnpublic/mysql-proxy/trunk mysql-proxy

# Enter the directory and bootsrap autoconf/automake
$ cd mysql-proxy
$ sh ./autogen.sh

# Build the source distribution tarball
$ ./configure && make distcheck

# Convert the source tarball into a binary RPM
$ rpmbuild -tb --clean mysql-proxy-<version>.tar.gz

RPM will now perform the compiling and packaging. The end result will be an installable binary RPM package which will end up in the RPMS directory. Depending on your distribution this location will vary, on my openSUSE system the package ended up in in the following location from where I installed it directly:

$ sudo rpm -Uhv /usr/src/packages/RPMS/i586/mysql-proxy-0.5.1-0.i586.rpm

The mysql-proxy will be installed into /usr/sbin, the documentation and example scripts are being put into the default documentation directory (/usr/share/doc/packages/mysql-proxy in my case).

For now, you still have to start the proxy manually. Next thing is to create an init script that starts up the process at boot time.

After I published my article on how to build MySQL with the new Falcon storage engine from source, the free BitKeeper client was updated to version 2.0. I have now updated the instructions accordingly, our manual has been updated to reflect these changes, too.

However, it is currently still not possible to clone the Falcon tree with this client, some kind of obscure locking error message appears, even though the admin console on bkbits.net does not reveal any active locks in the repository:

$ bkf clone bk://mysql.bkbits.net/mysql-5.2-falcon mysql-5.2-falcon
ERROR-unable to lock repo for export, try later.

We're aware of this problem and have already contacted BitKeeper support about this. I hope it can be resolved quickly...

Now that the source tree for the new Falcon Storage Engine is finally public, here's a quick HOWTO on how to compile the server from source. This procedure is described in more detail in the MySQL Manual. I assume you use Linux and have the required development toolchain installed.

You first should get the free BK client from http://www.bitmover.com/bk-client2.0.shar, unpack and install it:

$ wget http://www.bitmover.com/bk-client2.0.shar
--17:34:34--  http://www.bitmover.com/bk-client2.0.shar
           => `bk-client2.0.shar'
Resolving www.bitmover.com... 192.132.92.2
Connecting to www.bitmover.com|192.132.92.2|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 17,676 (17K) [application/x-shar]

100%[========================================================>] 17,676        33.56K/s

17:34:35 (33.50 KB/s) - `bk-client2.0.shar' saved [17676/17676]

$ sh ./bk-client2.0.shar
x - creating lock directory
x - creating directory bk-client2.0
x - extracting bk-client2.0/Makefile (text)
x - extracting bk-client2.0/bkf.c (text)
x - extracting bk-client2.0/demo.sh (text)

$ cd bk-client2.0
$ make
cc -O2 -Wall -Wno-parentheses    bkf.c   -o bkf
$ sudo install -m755 bkf /usr/local/bin

Now that the BK client is installed, we can create a local clone of the Falcon development tree:

$ bkf clone bk://mysql.bkbits.net/mysql-5.2-falcon mysql-5.2-falcon

This will now perform a check out the most recent source tree from the mysql-5.2-falcon repository (~83 MB of source code). You can now enter the newly created directory and start the build:

$ cd mysql-5.2-falcon
$ ./BUILD/compile-pentium-debug-falcon

If you have a x86_64 Linux system, use compile-amd64-debug-falcon instead. Depending on the performance of your system, this step will take a while, as it performs a full compile of the MySQL server and all related tools. Once the build completed with no errors, you can create a binary tarball distribution:

./scripts/make_binary_distribution

This should leave you with a tarball mysql-5.2.0-falcon-alpha-linux-i686.tar.gz that you can now install to, say, /usr/local:

$ tar zxvf mysql-5.2.0-falcon-alpha-linux-i686.tar.gz -C /usr/local
$ cd /usr/local
$ ln -s mysql-5.2.0-falcon-alpha-linux-i686 mysql
$ cd mysql
$ ./configure

The last command will install the privilege tables and start up the mysql server. You can now fire up the mysql client:

$ ./bin/mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.2.0-falcon-alpha-debug

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

Now make sure that falcon has indeed been included:

mysql> SHOW VARIABLES LIKE 'have_falcon';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| have_falcon   | YES   |
+---------------+-------+
1 row in set (0.01 sec)

Looks good! Now it's time to actually create a table that uses the Falcon engine:

mysql> use test;
Database changed
mysql> CREATE TABLE names (id INT, fname VARCHAR (20), lname VARCHAR (20)) ENGINE=Falcon;
Query OK, 0 rows affected (2.84 sec)

mysql> describe names;
+-------+-------------+------+-----+---------+-------+
| Field | Type        | Null | Key | Default | Extra |
+-------+-------------+------+-----+---------+-------+
| id    | int(11)     | YES  |     | NULL    |       |
| fname | varchar(20) | YES  |     | NULL    |       |
| lname | varchar(20) | YES  |     | NULL    |       |
+-------+-------------+------+-----+---------+-------+
3 rows in set (0.01 sec)

mysql> INSERT INTO names VALUES (0, 'Lenz', 'Grimmer');
Query OK, 1 row affected (0.03 sec)

mysql> INSERT INTO names VALUES (1, 'Monty', 'Widenius');
Query OK, 1 row affected (0.06 sec)

mysql> SELECT * FROM names WHERE lname='Widenius';
+------+-------+----------+
| id   | fname | lname    |
+------+-------+----------+
|    1 | Monty | Widenius |
+------+-------+----------+
1 row in set (0.00 sec)

Congratulations, you are ready to further test and explore this new storage engine! Have fun with testing it - we would appreciate your feedback and experiences! Please share your impressions via the Falcon Forum or report bugs via our Bug Database. Make sure to read the bug reporting guidelines on the MySQL Forge Wiki first!

UPDATE: The people at Bitkeeper updated the free BK client to version 2.0 after I wrote this. I updated the described procedure above accordingly. Currently, the repository seems to have a locking problem that only appears when using the free BK client. We are working with the BitKeeper team on resolving this issue.