Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Detect ddl add handlers #323
Detect ddl add handlers #323
Changes from all commits
bcbc111
4f87b90
ba70310
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the
defaultEventHandler
fires events to theeventListeners
, but if one were to override theeventHandler
,eventListeners
will no longer be called? This also means that the default event listener that handles the row event (by sending it to the BinlogWriter) will no longer be called. You would have to manually reregisterhandleRowEvent
as a eventHandler? This feels very confusing and somewhat error prone? Are there any cases where we don't want to row events to be handled as well?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shivnagarajan and I discussed this briefly: the event listeners would only be missed if a custom handler for
ROWS_EVENT
was registered (overwriting the default handler behaviour). The problem is that the callers would not have access tos.eventListeners
if they did want to fire them off themselves. That's probably okay since we are providing a hook into event handling and not a hook into the bodies of built-in event handlers themselves.There are a few ways to tackle this, that I wanted to summarize:
Accept this limitation and note it in the documentation (possibly as a gotcha).
This is the current approach. If there is demand for this, we can later come back and adopt one of the alternative approaches later.
Always firing off the
eventListeners
forROWS_EVENT
, even if a custom handler had been registered.This would solve the specific problem
This solves the specific problem of firing off the listeners for
ROWS_EVENT
without increasing the surface area of the API exposed to the handler, but it will be a surprising, snowflake-y behaviour which cannot be turned off even if you wanted to.Make
eventListeners
available to the callers inside the handler so that they can do with them as they wish.This solves the whole problem at the cost of muddling the handler signature with data unrelated to the event state. Moreover, the listeners are currently only be useful for one specific event but would need to be a part of the signature for handlers of all events (this is perhaps not too bad but still seems unnecessary).
Another approach not considered here?
I think we should go with the first option for now and revisit later if needed, FWIW.
Separately, I think if we wanted to be "truly" flexible in handler design then we should get to a place where all our default handlers could be registered as custom handlers instead of being implemented in a private fallback function. But we don't need to take on that complexity all at once.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK the first option sounds OK for the time being.
I suspect this part of the code will need to be revisited if we ever look into a larger restructure of Ghostferry as I think the complexity is increasing with this change (and also would with any other changes proposed). Perhaps the callback system would need to be revamped 🤷 , but that's a problem for another day.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noice!