----------------------------------------------------------------------- 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)