The initial release of the FederatedX Pluggable Storage Engine for MySQL is now
available. I developed the Federated Storage Engine when I worked at MySQL,
and really saw a lot of potential with it. However, there were many other
projects that I had to give attention to, and many features and bug fixes that
users wanted didn't come into fruition because of the busy schedule. I left
MySQL a year ago to pursue an opportunity with Grazr what has kept me equally
busy. However, I have made a resolution this year to give some projects that I
have wanted to improve the attention that they need. I still see a lot of
potential with the "federated" concept.

Federated as it is isn't what many people expect it to be. IBM for instance,
has a federation as a very integral part of DB2. The Federated Storage Engine
is a proof-of-concept storage engine -- not to say it doesn't …

Now that you can load an engine, we are going to look at reading data. For this we will need to implement three methods. We will also need the following schema:

CREATE TABLE `services` (
`a` varchar(125) NOT NULL DEFAULT '',
`b` text
) ENGINE=SKELETON DEFAULT CHARSET=latin1



Storage engines provide "handler" objects that are used to read/write/update tables. They inherit from the handler class defined in sql/handler.h.
The file ha_skeleton.cc holds the implementation of the handler for the Skeleton engine. Once a handler object is created it is cached and can be used for different tables that a particular storage engine controls. MySQL uses the open() and close() methods of handler object to tell the handler what table it should currently work with.

open() and close() are not called for each usage of a table, or each usage of a transaction.

For …

So I’ve been looking into the Archive Storage Engine. What I would really like to do with it is get data in realtime, because (of course) the higher-ups want reports on realtime data — that is, they are not satisfied with a report that is run regularly, they want all the data up until “now”.

It is inadvisable to replicate from one storage engine type to another. I have not yet played with it, but since an Archive table doesn’t allow updates and deletes, replicating from a MyISAM or InnoDB table to an Archive one is a bad idea.

Most folks probably run a batch job; but I wonder if it can be done in real-time. Or rather, ‘what is the best way to run it real-time?’ One way, off the top of my head, is to do this are to replicate to a blackhole table with a trigger, to insert into an archive table whenever an INSERT statement is called. The blackhole table should not give an error upon UPDATE or DELETE statements.

…