The new Value implementation is now based on the vitess types.
* The inner interface has now been replaced by typ and val.
* All Values are expected to be consistent with their types.
For example, an Int64 type must contain a number.
* The functions that build values generally ensure consistency.
* There is a set of 'Trusted' functions that can bypass this
consistency check. They should be used with care.
* The proto3 conversion functions build the correct Value types
based on the field types.
* The bson conversion function provides a Repair function that
allows you to fix up the types after the fact. This should be
deleted after bson is deprecated.
* The building of Values from a QueryResult is non-trivial because
the field info is not part of the QueryResult for streaming
queries. So, the API requires fields to be explicitly passed in.
* Fuctions that encode or convert to native types expect Value
to be consistent. If not, they panic.
* proto3.QueryResult is considered to be trusted. If it contains
inconsistent data, it will cause panics.
* The EventStreamer has been fixed to ensure that the fields and
rows it publishes are trustable: They can used as parameters
to the Trusted API.
* The Raw() function usage has been minimized. We should see if
it can be deprecated. This way, we can make Result truly read-only.
There are a few more tweaks that need to be done:
* The Proto3ToResult call plumbing was hacked in to make everything
work. That part needs cleaning.
* The bind vars don't need to be converted to their native types
any more.
This part 1 of the QueryResult revamp. With this change,
vitess does not see any MySQL types. The BSON layer still
sends mysql types for backward compatibility, which will
be deleted once deprecated.
1. bind variables in SplitQuery should not contain leading ':'.
2. fix custom_sharding.py test to pass through returned bind variables from VTGate.
3. fix SplitQuery tests in Java.
1. SplitQuery will split a VARBINARY column as a hex string. That is, it assumes
the key range is [0x0000000, 0xFFFFFFFF] and then divides the range into
intervals based on split count.
2. Introduce splitBoundariesStringColumn to handle string column case.
3. Refactor existing SplitQuery in sqlquery.go: create two helper functions
getColumnType and getColumnMinMax.
Fix for issue https://github.com/youtube/vitess/issues/797.
Names that used keywords were not always getting back-quoted
correctly during codegen. This is a comprehensive fix that
covers all such possible cases.
1. Add SplitColumn field to SplitQuery so that caller could hint SplitQuery endpoint
which column is best for splitting query.
2. The split column must be indexed and this will be verified on the server side.
3. coding style fixes suggested by golint.
1. Add SessionId to SplitQueryRequest
2. Do not panic if a table contains no rows, just return empty set of
boundaries.
3. Remove panic style error handling and explicitly return errors
Currently GetMRSplits creates one split per shard. This change allows
for further splitting within a shard for better parallelism in mappers.
Splits within a shard are created by appending primary key range clauses
to the shard level query.
Changes:
Added SplitQuery RPC to VtTablet
Modified GetMRSplits to accept SQL queries instead of Table and columns
GetMRSplits forwards the query to tablet for splitting via scatterConn
Unit tests
Sugu Sougoumarane
Shengzhe Yao
Anand Henry