apache /
kudu /
295b4903bc69fabb3cb36f618022d465c91954c7 KUDU-2671 more robust convention on specifying range bounds
This patch updates the code of the catalog manager to adhere to a more
robust convention on specifying the information for the range partition
boundaries when creating a table with custom hash schemas per range.
Prior to this patch, the catalog manager required both the
CreateTableRequestPB::split_rows_range_bounds and the
CreateTableRequestPB::partition_schema::custom_hash_schema_ranges fields
to have the same number of elements, assuming the former had the ranges
exactly corresponding to the latter, where the latter would also had
information on hash schema for each range correspondingly. In addition
to duplicating the information unnecessarily, that approach was also
a bit brittle from the standpoint of keeping good API practices.
This patch updates the code to use a new convention: if there is at
least one range partition with custom hash schema in CreateTable RPC,
all the information on range boundaries and hash schemas should be
presented only via one field:
CreateTableRequestPB::partition_schema::custom_hash_schema_ranges.
That's better than the previous convention because:
* it's more robust as explained above
* it naturally follows the restriction of not allowing the split
rows along with range partitions with custom hash schemas
Also, I updated already existing tests and added extra test scenarios
to cover the updated functionality.
Change-Id: I14073e72178e6bb85bae719ad377c5bb05f8dd55
Reviewed-on: http://gerrit.cloudera.org:8080/18590
Tested-by: Alexey Serbin <alexey@apache.org>
Reviewed-by: Mahesh Reddy <mreddy@cloudera.com>
Reviewed-by: Attila Bukor <abukor@apache.org>
4 files changed
