apache /
kudu /
e0f96b9c838e33b93690a76f771d1eeaf3a99222 KUDU-2671 forward-looking provision for AddRangePartition
The way how the information on range-specific hash schema is specified
in AlterTableRequestPB::AddRangePartition introduced by [1] assumes
there should not be an empty custom hash schema for a range when the
table-wide hash schema isn't empty. As of now, the assumption holds
true since there is an artificial restriction on the variability of the
number of dimensions in per-range hash schemas in a table introduced
by changelist [2]. However, once the restriction introduced in [2] is
removed, the current type of the AddRangePartition::custom_hash_schema
deprives the code to tell between the case of a range-specific hash
schema with zero hash dimensions (a.k.a. empty hash schema, i.e. no hash
bucketing at all) and the case of table-wide hash schema for a newly
added range partition.
This patch fixes the deficiency, so now it's possible to call
has_custom_hash_schema() and hasCustomHashSchema() on AddRangePartition
object in C++ and Java code correspondingly, not relying on the
emptiness of the repeated field representing the set of hash dimensions
for the range-specific hash schema.
This patch would break backwards compatibility if there were a version
of Kudu released with the change introduced in changlist [1], but that's
not the case. So, it was possible to simply change the type of the
AddRangePartition::custom_hash_schema field.
[1] https://github.com/apache/kudu/commit/11db3f28b36d92ce1515bcaace51a3586838abcb
[2] https://github.com/apache/kudu/commit/6998193e69eeda497f912d1d806470c95b591ad4
Change-Id: I30f654443c7f51a76dea9d980588b399b06c2dd1
Reviewed-on: http://gerrit.cloudera.org:8080/18713
Tested-by: Alexey Serbin <alexey@apache.org>
Reviewed-by: Mahesh Reddy <mreddy@cloudera.com>
Reviewed-by: Abhishek Chennaka <achennaka@cloudera.com>
Reviewed-by: Alexey Serbin <alexey@apache.org>
5 files changed
