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

Add data_block_encoding parameter to Phoenix connector. #4617

Merged
merged 1 commit into from
Aug 7, 2020
Merged

Add data_block_encoding parameter to Phoenix connector. #4617

merged 1 commit into from
Aug 7, 2020

Conversation

lhofhansl
Copy link
Member

DATA_BLOCK_ENCODING is a common parameter that Phoenix users might want to set (along with Compression), so we should add this.

(There are in fact a bunch of more HBase column family level options that Phoenix also supports, but most of them are not common, and should be probably set directly within Phoenix)

@cla-bot cla-bot bot added the cla-signed label Jul 29, 2020
if (value == null) {
return Optional.empty();
}
return Optional.of(value);
Copy link
Member

Choose a reason for hiding this comment

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

Can we use Optional.ofNullable

Copy link
Member Author

Choose a reason for hiding this comment

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

I fixed all the occurrences here, as that just seemed right and no functional change at all.

@@ -109,6 +110,11 @@ public PhoenixTableProperties()
TTL,
"Number of seconds for cell TTL. HBase will automatically delete rows once the expiration time is reached.",
null,
false),
stringProperty(
Copy link
Member

Choose a reason for hiding this comment

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

Can we have a enum property for this like we define STORAGE_FORMAT_PROPERTY for HiveTableProperties

Copy link
Member Author

Choose a reason for hiding this comment

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

In both cases I just followed the existing code. I think if we change that, it is for all other parts too, and then we're mixing concerns of PRs.

Copy link
Member Author

Choose a reason for hiding this comment

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

Let me know if you want me to fix all the other instances as well in this PR or file a separate one.

Copy link
Member

Choose a reason for hiding this comment

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

It would be better if we could fix all the other instances also. Maybe we can have s separate PR for them ?

Copy link
Member Author

Choose a reason for hiding this comment

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

I fixed the Optional use below. The property list change should be a separate PR IMHO.

@lhofhansl
Copy link
Member Author

Also updated the documentation (including a fix for the Bloomfilter default, which is NONE instead of ROW).

Copy link
Member

@Praveen2112 Praveen2112 left a comment

Choose a reason for hiding this comment

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

Thanks for working on it

}

public static Optional<Integer> getTimeToLive(Map<String, Object> tableProperties)
{
requireNonNull(tableProperties);

Integer value = (Integer) tableProperties.get(TTL);
if (value == null) {
Copy link
Member

Choose a reason for hiding this comment

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

Can we capture them in a separate commit ?

Copy link
Member Author

Choose a reason for hiding this comment

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

Then let's do separate PRs. I'll undo this change, and just make sure the new code uses ofNullable.
What about the documentation fixes. Maybe it's best to separate the fix for the Bloomfilter doc as well.

@lhofhansl
Copy link
Member Author

OK... I changed it back to the minimum required to fix the issue at hand. Let's merge this one (assuming it's OK) and then I'll file followup PRs for the trivial fixes.

Copy link
Member

@Praveen2112 Praveen2112 left a comment

Choose a reason for hiding this comment

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

Thanks for working on this !! Looks good to me

false),
stringProperty(
DATA_BLOCK_ENCODING,
"The block encoding algorithm to use for Cells in HBase blocks. Options are: PREFIX, DIFF, FAST_DIFF, ROW_INDEX_V1, and others.",
Copy link
Member

Choose a reason for hiding this comment

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

Did we miss None and PREFIX_TREE encoding technique ?

Copy link
Member

Choose a reason for hiding this comment

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

Can we add the same in the doc too

Copy link
Member Author

@lhofhansl lhofhansl Aug 3, 2020

Choose a reason for hiding this comment

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

PREFIX_TREE is not finished in HBase, nobody should use it.
And there really is no reason to use PREFIX or DIFF (since FAST_DIFF is better and faster than both).
Yep. None is missing. And also, yes, it should consistent with the documentation.

Copy link
Member Author

Choose a reason for hiding this comment

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

Updated.

@lhofhansl
Copy link
Member Author

I'll fix the test failure. Phoenix currently happens to set the HBase DATA_BLOCK_ENCODING to FAST_DIFF, but HBase has no default (it's NONE).
If Phoenix ever changes the default we wouldn't show it in SHOW CREATE TABLE... Hence it's displayed if other than NONE.

@lhofhansl
Copy link
Member Author

Good to go, @Praveen2112?

@Praveen2112 Praveen2112 merged commit 41b796a into trinodb:master Aug 7, 2020
@Praveen2112
Copy link
Member

Merged !! Thanks for raising this PR

@Praveen2112 Praveen2112 mentioned this pull request Aug 7, 2020
8 tasks
@lhofhansl
Copy link
Member Author

Thanks @Praveen2112

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.

2 participants