{"id":1874,"date":"2010-03-30T15:06:17","date_gmt":"2010-03-30T05:06:17","guid":{"rendered":"http:\/\/www.flamingspork.com\/blog\/?p=1874"},"modified":"2014-10-08T09:16:07","modified_gmt":"2014-10-07T23:16:07","slug":"storing-the-table-message-in-embedded-innodb","status":"publish","type":"post","link":"https:\/\/www.flamingspork.com\/blog\/2010\/03\/30\/storing-the-table-message-in-embedded-innodb\/","title":{"rendered":"Storing the table message in Embedded InnoDB"},"content":{"rendered":"

One of the exciting things[1] about working on a storage engine in Drizzle<\/a> is that you get to manage your own metadata. When the database engine you’re writing the storage engine interface for has a pretty complete data dictionary (e.g. Embedded InnoDB<\/a>) you could just directly use it. At some point I plan to do this for the embedded_innodb engine for Drizzle so that you could just point Drizzle at an existing Embedded InnoDB database and run SQL queries on it.<\/p>\n

The Drizzle table message does have some things in it that aren’t in the InnoDB data dictionary though (e.g. table and column comments). We want to preserve these (and also things like there may be several data types in Drizzle that map to the same data type in InnoDB). Since the Embedded InnoDB API allows us to do things within the DDL transaction (such as insert a row into a table), we store the serialized table message in a table as part of the DDL transaction. This means we can have fully crash safe DDL<\/strong>! There is no way the table definition can get out of sync with what is in InnoDB; we are manipulating them both in the same transaction!<\/p>\n

The table structure we’re using is pretty simple. There is two columns: table_name VARCHAR(IB_MAX_TABLE_NAME_LEN) and message BLOB.<\/p>\n

The operations we need are:<\/p>\n