In my rare spare time work on the Binlog Storage Engine: MySQL Proxy Edition and for a few days I was wondering why my index-based JOINs didn't worked. With a index it works, with an index nothing is returned.

I narrowed it down to a simple test-case:

select * from test AS a JOIN test AS b USING (event_pos) WHERE a.event_pos IN (106);
...
1 row in set (0.03 sec)

EXPLAIN
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table | type  | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+-------+-------+---------------+---------+---------+-------+------+-------+
|  1 | SIMPLE      | a     | const | PRIMARY       | PRIMARY | 4       | const |    1 |       | 
|  1 | SIMPLE      | b     | const | PRIMARY       | PRIMARY | 4       | const |    1 |       | …

Hartmut was asking me some time ago how table discovery in the storage engine interface works. After reading through the code from ndb, archive and memcache I was a bit disappointed: all of them are just copying the definition in binary form around.

For the wormhole SE the lua-file has to create table structure on the fly. You only drop in the .lua into the db-folder and a SELECT will pick it up automaticly.

We use a small function which returns the table definition:

function discover()
        return {
                { name = "fld1", type = 1 },
                { name = "fld2", type = 2 },
                { name = "fld3", type = 15, length = 64 }
        }
end

A SHOW CREATE TABLE against the table shows us:

root@127.0.0.1:test> show create table foobar\G
*************************** 1. row ***************************
       Table: foobar
Create Table: CREATE TABLE `foobar` (
  `fld1` tinyint(4) …

I got a few comments about my last example not describing a wormhole, but a whitehole. Time to improve the picture a bit and getting data from another dimension on a shorter route than the long standard way.

To use the picture let's take a look at what has been done:

root@127.0.0.1:test> select * from finance where symbol = "MSFT";
+--------+------------+---------------------+--------------+------------+-----------+-----------+----------+
| symbol | last_trade | trade_time          | trade_change | open_trade | max_trade | min_trade | volume   |
+--------+------------+---------------------+--------------+------------+-----------+-----------+----------+
| MSFT   |      29.84 | 2007-10-05 00:00:00 |         0.13 |      29.84 |     29.99 |     29.73 | 45016520 | 
+--------+------------+---------------------+--------------+------------+-----------+-----------+----------+

root@127.0.0.1:test> select * from finance; …

MySQL has a quite unique feature: the pluggable storage engine interface. Thanks to it MySQL supports different Storage Engines for different needs: MyISAM is perfect for heavy read, InnoDB for transational data and blackhole .... for sending data to /dev/null.

Thanks to some advance science we now have a wormhole Storage Engine. While the blackhole can only be written to but nothing ever comes back, the wormhole is the inverse of it. You get data from another galaxy, but all writes might have no effect on your side. Sounds useful ?

What's the deal ? The wormhole SE is a lua-based storage engine. The data is "stored" in a script-language. ... Ok, this explaination doesn't help very much. Let's take a look at an example:

The CREATE TABLE for a wormhole table is pretty simple. No magic:

1
2
3
4