maria-developers team mailing list archive

[worklog-noreply@xxxxxxxxxxxx]

-----------------------------------------------------------------------
                              WORKLOG TASK
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
TASK...........: Event applier API
CREATION DATE..: Fri, 27 Aug 2010, 13:17
SUPERVISOR.....: Sergei
IMPLEMENTOR....: Knielsen
COPIES TO......: 
CATEGORY.......: Server-Sprint
TASK ID........: 133 (http://askmonty.org/worklog/?tid=133)
VERSION........: Server-9.x
STATUS.........: Assigned
PRIORITY.......: 60
WORKED HOURS...: 0
ESTIMATE.......: 0 (hours remain)
ORIG. ESTIMATE.: 0

PROGRESS NOTES:



DESCRIPTION:

A part of the replication project, MWL#107.

The event applier API does the opposite of the stacked event generator API,
MWL#120. It allows a plugin to apply (=execute) abstract events on a slave.

Just like generated events from MWL#120 are abstract without any fixed
materialised format, applied events are also abstract with no fixed
materialised format imposed by the API. All event data is supplied by the
plugin by calling "provider" methods in applier objects obtained from the
API. This allows the plugin to choose which information to supply. For
example, one plugin may supply row event values identified by column name,
while another may supply by column poisition. Using a provider interface,
different plugins can supply different information, as long as the provided
information is sufficient for the applier API to execute the event in _some_
way.

The event applier API also need to provide a facility for initialising a
thread (or multiple threads) to be able to execute events (setting up THD
etc).

Event appliers are stacked, just like event generators.

For example, row-based events are stacked on statement-based events. So a row
event applier can accept statement events in addition to row events (and
recursively also accept transaction events, as statement-based is stacked on
transaction-based).

On top of the detailed interfaces for event generation and application, one
can build simple materialised event formats, which are just byte strings
containing all necessary information.

On the generator side, this can be done as a filter that consumes row-based
events (say) and encapsulates them in some way (say Google protobuf
packets).

On the applier side, it can be done by implementing a simple event applier
class, that has a single provider method only, accepting a materialised event
packet.

The strength of the full abstraction below this is that it is possible to
implement arbitrary such materialised event formats in plugins, and possible
to implement event format plugins and event transport plugins independent of
each other.


ESTIMATED WORK TIME

ESTIMATED COMPLETION DATE
-----------------------------------------------------------------------
WorkLog (v4.0.0)