![](https://secure.gravatar.com/avatar/3c2329333dd5898f2e72818af773243d.jpg?s=120&d=mm&r=g)
Hi, Kristian!
API, eliminating lots of class definitions and accessor functions. Though arguably it wouldn't really simplify the API, as the complexity would just be in understanding the THD class.
For now, the API is proposed without exposing the THD class. (Similar encapsulation could be added in actual implementation to also not expose TABLE and similar classes).
completely agree
Ok, so some follow up questions:
1. Do I understand correctly that you agree that the API should also encapsulate TABLE and similar classes? These _are_ exposed to storage engines as far as I can see.
I think it's ok to use TABLE and Field as storage engines are using them. It would be good to encapsulate them, of course, but I'd say there's no need to try to do it at all costs.
2. If TABLE and so on should be encapsulated, there will be the issue of having iterators to run over columns, etc. Do we already have standard classes for this that could be used? Or should I do this modelled using the iterators of the Stardard C++ library, for example?
We have List and an iterator over it. Alternatively, you can return an array and let the caller iterate it any way it wants.
(I would like to make the new API fit in as well as possible with the existing MySQL/MariaDB code, which you know much better).
A consumer is implented as a virtual class (interface). There is one virtual function for every event that can be received. A consumer would derive from
hm. This part I don't understand. How would that work ? A consumer want to see a uniform stream of events, perhaps for sending them to a slave. Why would you need different consimers and different methods for different events ?
I'd just have one method, receive_event(rpl_event_base *)
Ok, so do I understand you correctly that class rpl_event_base would have a type field, and the consumer could then down-cast to the appropriate specific event class based on the type?
receive_event(const rpl_event_base *generic_event) { switch (generic_event->type) { case rpl_event_base::RPL_EVENT_STATEMENT_QUERY: const rpl_event_statement_query *ev= static_cast
(generic_event); do_stuff(ev->get_query_string(), ...); break; case rpl_event_base::RPL_EVENT_ROW_UPDATE: const rpl_event_row_update *ev= static_cast (generic_event); do_stuff(ev->get_after_image(), ...); break; ... } } I have always disliked having such type field and upcasting. So I tried to make an API where it was not needed. Like this:
class my_event_consumer { int stmt_query(const rpl_event_statement_query *ev) { do_stuff(ev->get_query_string(), ...); } int row_update(const rpl_event_row_update *ev) { do_stuff(ev->get_after_image(), ...); } ... };
Okay, now I see what you mean. I don't like downcasting either. On the other hand, I don't want to force plugins that work on an event as a whole to implement methods for every particular type of an event. It may be possible to do both. Like - virtual methods for every event type, as you proposed, but not abstract - the default implementation calls receive_event() - a generic one. And a plugin can either implement a family of receive_event* methods or a generic. But if the above wouldn't work and we'll have to choose, I'd prefer a simpler interface with one generic receive_event().
One generator can be stacked on top of another. This means that a generator on top (for example row-based events) will handle some events itself (eg. non-deterministic update in mixed-mode binlogging). Other events that it does not want to or cannot handle (for example deterministic delete or DDL) will be defered to the generator below (for example statement-based events).
There's a problem with this idea. Say, Event B is nested in Event A:
... ... |<- Event A ... .. .. ->| .. .. .. * * * * * |<- Event B ->| * * * *
This is fine. But what about
... ... |<- Event A ... ->| .. .. .. * * * * * |<- Event B ->| * * * *
In the latter case no event is nested in the other, and no level can simply dever to the other.
I don't know a solution for this, I'm just hoping the above situation is impossible. At least, I could not find an example of "overlapping" events.
Another way of thinking about this is that we have one layer above handling (or not handling) an event that can be generated below. ... So one case where this becomes a problem is if we have a multi-table update where one table is PBXT and another is not, and we are using PBXT engine-level replication on top of statement-based replication. In this case, one half of the statement-based event is handled by the layer above, but the other is not. So we cannot deal with this situation.
On the opposite, this is quite easy. Even a CREATE ... SELECT is a mix of statement-based and row-based. A simple solution would be to replicate it completely statement-based - that is, to discard the row-based part of the event. We can do that, because statement level description of the event is sufficient - the row based evetn is completely nested within a statement-based one (other, more complex solutions are possible too). I was describing a case when events overlap, but neither one is completely nested within the other. This case I know no solution for, but I hope it is never possible in practice. Regards, Sergei