Mats Kindahl wrote: > AFAICT, all of the "editing" cases I can envision can be solved by a > proper API to the replication log (but if you have some cases, real or > imaginary, that you think can pose a problem I would be happy to hear > them).
Mats - I started work 2 or 3 times now on splitting log_event/binlogging stuff into a lib, mainly driven by my severe hatred of drizzlebinlog.cc including log_event.cc, except that in drizzlebinlog.cc MYSQL_CLIENT is defined instead of MYSQL_SERVER... Each time I've gone too quickly and broken something... but I'd love to keep working on this. Perhaps we could start laying out a plan to: 1) Split log_event.cc into files for each log_event class 2) Merge the code so that there is no branching for client/server or if we do need a special class for client code (keeping the print methods out of the server, for instance, or insulating client from THD) we make some visitor classes or something 3) Make a proper libdrizzlebinlog lib that can be used to interact with some of this? If we have a proper lib, then we can make language bindings really easily (perl, python, lua, whatever) > As tools support, I am considering libraries to allow "playing" > replication logs in a controlled manner using scripts, with scripting > language either being Lua or Perl (or maybe both, it depends on where I > put the scripting support). On the other hand, even if it's just a convenience lib, I'd be happier. Monty _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
