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

Refactor Phoenix MERGE implementation #23114

Merged
merged 4 commits into from
Sep 4, 2024

Conversation

chenjian2664
Copy link
Contributor

@chenjian2664 chenjian2664 commented Aug 23, 2024

Description

Additional context and related issues

Release notes

(x) This is not user-visible or is docs only, and no release notes are required.

@cla-bot cla-bot bot added the cla-signed label Aug 23, 2024
@chenjian2664 chenjian2664 requested a review from kokosing August 23, 2024 15:44
@chenjian2664 chenjian2664 marked this pull request as ready for review August 23, 2024 15:45
@chenjian2664 chenjian2664 force-pushed the refat_jdbc_sink branch 9 times, most recently from 6c77aa4 to 556f1c9 Compare August 29, 2024 15:24
@chenjian2664 chenjian2664 force-pushed the refat_jdbc_sink branch 2 times, most recently from c6eade8 to 6355ba3 Compare September 2, 2024 07:17
@chenjian2664 chenjian2664 changed the title Refactor JdbcPageSink constructor to allow pass sink sql Refactor Phoenix MREGE implementation Sep 2, 2024
@kokosing kokosing changed the title Refactor Phoenix MREGE implementation Refactor Phoenix MERGE implementation Sep 2, 2024
@kokosing
Copy link
Member

kokosing commented Sep 2, 2024

@hashhar @ebyhr any comments?

This allow us avoid to call non-static method in the JdbcPageSink.
Also avoid call non-static method in PhoenixMergeSink and remove the unnecessary internal classes DeleteSink and UpdateSink
Use static method in PhoenixMergeSink to create the `updateSink` and `deleteSink` to eliminate the dependency on the order of statements
Follow the params order in the `JdbcPageSink`
@kokosing kokosing merged commit c355092 into trinodb:master Sep 4, 2024
64 checks passed
@kokosing
Copy link
Member

kokosing commented Sep 4, 2024

Thank you!

@github-actions github-actions bot added this to the 456 milestone Sep 4, 2024
@chenjian2664 chenjian2664 deleted the refat_jdbc_sink branch September 5, 2024 01:28
Comment on lines +343 to +349
// The TupleDomain for building the conjuncts of the primary keys
ImmutableMap.Builder<ColumnHandle, Domain> primaryKeysDomainBuilder = ImmutableMap.builder();
// This value is to build the TupleDomain, but it won't affect the query field in result of the `DefaultQueryBuilder#prepareDeleteQuery`
Domain dummy = Domain.singleValue(BIGINT, 0L);
for (JdbcColumnHandle columnHandle : phoenixClient.getPrimaryKeyColumnHandles(session, plainTable)) {
primaryKeysDomainBuilder.put(columnHandle, dummy);
}
Copy link
Member

Choose a reason for hiding this comment

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

this is the only thing that's a bit weird to me.

I don't understand why we say "it won't affect query".

The DefaultQueryBuilder can change in future. Either way it does use the tuple domain to create conjuncts by passing this to toConjuncts method.

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 for the review.

I don't understand why we say "it won't affect query".

The domain does not participate in building the conjuncts as long as it is the singValue domain, this is what I want, only use the column and bind exception. It's a bit awkward to reuse the DefaultQueryBuilder, but currently the DefaultQueryBuilder not support function only accept the column handles to only get sql string.

The DefaultQueryBuilder can change in future. Either way it does use the tuple domain to create conjuncts by passing this to toConjuncts method.

You are right, so after the merge got accept, the DefaultQueryBuilder needs to keep the correctness of the result that with the parameters: column & singDomain.
We need either implement a new query builder or provide/extract a new function to support the current situation to let the QueryBuilder more easily to maintain, I can have a try on it.:)

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for the explanation.

provide/extract a new function to support the current situation to let the QueryBuilder more easily to maintain, I can have a try on it.:)

I think this makes sense to do.

Copy link
Member

@hashhar hashhar left a comment

Choose a reason for hiding this comment

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

Nice work on this.

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

Successfully merging this pull request may close these issues.

3 participants