So, you’ve decided to write a Storage Engine for Drizzle. This is excellent news! The API is continually being improved and if you’ve worked on a Storage Engine for MySQL, you’ll notice quite a few differences in some areas.<\/p>\n
The first step is to create a skeleton StorageEngine plugin.<\/p>\n
You can see my skeleton embedded_innodb StorageEngine plugin in its merge request.<\/p>\n
The important steps are:<\/p>\n
e.g. create the plugin.ini file in the plugin directory (so it’s This gives us a title and description, along with telling the build system what sources to compile and what headers to make sure to include in any source distribution.<\/p>\n Your plugin may require extra libraries on the system. For example, the embedded_innodb plugin uses the Embedded InnoDB library (libinnodb).<\/p>\n Other examples include the MD5 function requiring either openssl or gnutls, the gearman related plugins requiring gearman libraries, the For embedded_innodb, pandora-build has a macro for finding libinnodb on the system. We want to run this configure check, so we create a plugin.ac file in the plugin directory (i.e. For embedded_innodb, the plugin.ac file just contains this one line:<\/p>\n We also want to add two things to plugin.ini; one to tell the build system only to build our plugin if libinnodb was found and the other to link our plugin with libinnodb. For embedded_innodb, it’s these two lines:<\/p>\n Some plugins (such as the md5 function) have a bit more custom auto-foo in plugin.ini and plugin.ac (as one of two libraries can be used). You can do pretty much anything with the plugin system, but you’re a lot more likely to keep it simple like we have here.<\/p>\n While this will change a little bit over time (and is a little long to just paste into here), you can see what I did for embedded_innodb in the skeleton-embedded-innodb-engine<\/a> tree.<\/p>\n You will need to re-run You will probably want to add a test to see that your plugin loads successfully. When your plugin is built, the test suite automatically picks up any tests you have in the Since we are loading a plugin, we will also need some server options to make sure that plugin is loaded. These are stored in the rather inappropriately named You can have pretty much anything in the plugin_load.test file… if you’re fancy, you’ll have a Once you’ve added your test, you can run it either by just typing “ and you’re done. Well… the start of a Storage Engine plugin is done :)<\/p>\n This blog post (but not the whole blog) is published under the\u00c2\u00a0Creative Commons Attribution-Share Alike License<\/a>. Attribution is by linking back to this post and mentioning my name (Stewart Smith).<\/p>\n","protected":false},"excerpt":{"rendered":" So, you’ve decided to write a Storage Engine for Drizzle. This is excellent news! The API is continually being improved and if you’ve worked on a Storage Engine for MySQL, you’ll notice quite a few differences in some areas. The … Continue reading mkdir plugin\/embedded_innodb<\/code><\/p>\n2. Create the plugin.ini file describing the plugin<\/h2>\n
plugin\/plugin_name\/plugin.ini<\/code>)
\nAn example plugin.ini for embedded_innodb is.<\/p>\n[plugin]\r\ntitle=InnoDB Storage Engine using the Embedded InnoDB library\r\ndescription=Work in progress engine using libinnodb instead of including it in tree.\r\nsources=embedded_innodb_engine.cc\r\nheaders=embedded_innodb_engine.h<\/pre>\n
3. Add plugin dependencies<\/h2>\n
UUID()<\/code> function requiring libuuid and BlitzDB requiring Tokyo Cabinet libraries.<\/p>\nplugin\/plugin_name\/plugin.ac<\/code>) and add the check to it.<\/p>\nPANDORA_HAVE_LIBINNODB<\/pre>\n
build_conditional=\"x${ac_cv_libinnodb}\" = \"xyes\"\r\nldflags=${LTLIBINNODB}<\/pre>\n4. Add skeleton source code for your StorageEngine<\/h2>\n
5. Build!<\/h2>\n
.\/config\/autorun.sh<\/code> so the build system picks up your new plugin. When you run .\/configure --help<\/code> afterwards, you should see options for building with\/without your new plugin.<\/p>\n6. Add a test<\/h2>\n
plugin\/plugin_name\/tests<\/code> directory. This is in the same format as general MySQL and Drizzle tests: tests go in a t\/<\/code> directory, expected results in a r\/<\/code> directory.<\/p>\ntest-master.opt<\/code> file (that’s the test name with “-master.opt<\/code>” appended to the end instead of “.test<\/code>“). For the embedded_innodb plugin_load test, we have a plugin\/embedded_innodb\/tests\/t\/plugin_load-master.opt<\/code> file with the following content:<\/p>\n--plugin_add=embedded_innodb<\/pre>\n
SELECT<\/code> query on data_dictionary.plugins<\/code> to check that the plugin really is there. Be sure to also add a r\/plugin_load.result<\/code> file (My preferred method is to just create an empty result file, run the test suite and examine the rejected output before renaming the .reject<\/code> file to .result<\/code>)<\/p>\nmake test<\/code>” (which will run the whole test suite), or you can go into the main tests\/<\/code> directory and run .\/test-run.pl --suite=plugin_name<\/code> (which will just run the tests for your plugin).<\/p>\n7. Check the code in, feel good about self<\/h2>\n