Mats Kindahl wrote: > Hi Monty! > > Monty Taylor wrote: >> 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. > > Yes, the code is a pain and something that has been bothering me as well. > >> Perhaps we could start laying out a plan to: >> >> 1) Split log_event.cc into files for each log_event class > > Hmmm... I don't think that is a good split. The individual events are > part of an implementation, so I think they should go into a single file. > The Log_event class, however, is part of the interface, so it should go > into a separate file. OTOH, it doesn't hurt to put them in separate > files... hmm...
Well... I think the main thing with the separate files is similar to what we've done with field and are doing with item... break some of these bigger files up into more manageable chunks. Doesn't really affect the end-result as much as just gives us something easier to deal with. >> 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 > > Been in the back of my head for a long time. I've had many refactorings > in mind but have not been able to work on it since I've been fixing bugs > for a long time. :) Fixing bugs is boring. Also, I think if they'd let people refactor like we've been doing here, fixing bugs would be easier and the end time-frame would likely be the same. >> 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) > > You want me to do a refactoring as next task or do you want to do it > yourself with my help? Either one... I just know that there is enough going on that help would be nice... >>> 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. > > This is for the future, but the idea of a binlog API has been around for > some time and I get poked frequently about providing one. If I do the > job, can I move this patch to MySQL as well? I think that would be > beneficial to several people. Totally! I'm more than happy for patches to move back to MySQL if they make sense... or if someone wants to port them... 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
