Skip to content
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

Implement Tombstone Message Handling for JDBC Sink Connector #302

Merged
merged 1 commit into from
Jun 11, 2024

Conversation

Joel-hanson
Copy link
Contributor

Description:

This pull request addresses issue #165, focusing on enhancing the functionality of the JDBC sink connector to handle deletes on tombstone messages effectively. By implementing this feature, users can now delete rows corresponding to tombstone messages, which is particularly useful for scenarios involving Change Data Capture (CDC) from another database.

Changes:

  • Added support for handling tombstone messages in the JDBC sink connector.
  • Implemented the ability to delete rows based on tombstone messages.
  • Introduced a new parameter, delete.enabled, to control delete behavior.
  • Aligned functionality with the documented approach for processing tombstones, similar to Confluent JDBC driver behavior.

Related Issue(s):

Signed-off-by: Joel Hanson joelhanson025@gmail.com

@Joel-hanson
Copy link
Contributor Author

@ivanyu, could you please take a look at this pull request when you get a chance? Your feedback would be really valuable. Thank you!

@matuagarwal
Copy link

@jeqo @ivanyu could you please review the PR

if (records.isEmpty()) {
log.debug("Records is empty");
if (records.isEmpty() && tombstoneRecords.isEmpty()) {
log.debug("Records are empty.");

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit
I am not sure about this debug.

  • the debug text should include Records and tombstone records are empty.
  • Do we want to have a debug is the records are empty as before and there are tombstones .

Copy link
Contributor Author

@Joel-hanson Joel-hanson May 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to have a debug is the records are empty as before and there are tombstones.

It seems redundant to include if statements solely for debugging empty records, as the prepare statement debug (mentioned previously) will already cover this aspect by not debugging the statement if no records are there.

} else {
records.add(record);
}
if (records.size() >= config.batchSize || tombstoneRecords.size() >= config.batchSize) {
log.debug("Flushing buffered records after exceeding configured batch size {}.",

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit
might be worth adding in the records.size() and tombstoneRecords.size() so we know which one caused the flush

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @davidradl for the review, I have addressed most of the comments

@aindriu-aiven
Copy link

Hey @Joel-hanson, thanks a million for your contribution I have this on my list for review on Monday, sorry for the delay I am just catching up on a few projects at the moment!

records.add(record);
}
if (records.size() >= config.batchSize || tombstoneRecords.size() >= config.batchSize) {
log.debug("Flushing buffered records {} and tombstone records {} after exceeding the configured batch size of {}.",

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey,
Just started going through the PR but there are a couple of checkstyle errors on line 102 & Line 124 for lines that exceed 120 characters.

Copy link
Contributor

@C0urante C0urante left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @Joel-hanson for the PR! I've left a few thoughts but overall it looks pretty good.

I'm unable to run the integration tests on my Apple Silicon Macbook, though. I've tried several things (including looking through Testcontainers issues and using an alternative Docker runtime) with no success.

Would it be possible to use Postgres either instead of or in addition to Oracle for the new integration tests? As Apple Silicon becomes more and more prevalent for devs the cost of having tests that can't be run locally increases.

build.gradle.kts Outdated Show resolved Hide resolved
@Joel-hanson Joel-hanson force-pushed the support-delete branch 2 times, most recently from 2a27255 to 3aab7d2 Compare May 28, 2024 06:44
@Joel-hanson
Copy link
Contributor Author

@aindriu-aiven @C0urante I have addressed most of the comments. Could you please do a re-review?

Copy link
Contributor

@C0urante C0urante left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @Joel-hanson! This is looking really good. I've given all the changes to the main codebase and integration tests a pass. Still haven't looked at the unit tests yet; will try to do that in the next pass once these comments are addressed.

Also, please be sure to build the project locally before pushing more commits. You can do this with ./gradlew clean build; right now there are still a handful of Checkstyle errors that are causing the build to fail.

C0urante
C0urante previously approved these changes Jun 10, 2024
Copy link
Contributor

@C0urante C0urante left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks @Joel-hanson!

One last request--can you squash your commits into a single commit? No need to mention "address review comments" or anything like that, we just need a description that'll be helpful in the git history for the master branch after the merge.

- Add support for handling tombstone messages in the JDBC sink connector.
- Implement ability to delete rows based on tombstone messages.
- Introduce new parameter `delete.enabled` to control delete behavior.
- Align functionality with documented approach for
  processing tombstones, similar to Confluent JDBC driver behavior.
- Add new integration test with Oracle database.
- Implement integration tests for PostgreSQL and Oracle database
  to test insert and delete operations.
- Add new sink config validation for delete enabled config.
- Updated the docs to include the new config for sink connector.

Signed-off-by: Joel Hanson <joelhanson025@gmail.com>
Signed-off-by: Joel Hanson <joel.hanson2@ibm.com>
@Joel-hanson
Copy link
Contributor Author

LGTM, thanks @Joel-hanson!

One last request--can you squash your commits into a single commit? No need to mention "address review comments" or anything like that, we just need a description that'll be helpful in the git history for the master branch after the merge.

@C0urante Thanks, I have squashed the commit and updated the documentation file to include the delete.enabled configuration.

@C0urante C0urante merged commit bb19998 into Aiven-Open:master Jun 11, 2024
3 checks passed
@Joel-hanson Joel-hanson deleted the support-delete branch June 13, 2024 06:06
@Joel-hanson
Copy link
Contributor Author

@C0urante Thank you for merging PR. I was wondering if you could provide an estimate of when the next release will be published that includes these changes?

If there's anything I can do to assist with the release process, please let me know.

Thank you again for your support and for maintaining this project.

@C0urante
Copy link
Contributor

@Joel-hanson I've reached out to some people internally, will let you know when I hear back.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Handle deletes on tombstone messages
5 participants