This patch makes it so that the template arguments of
range<T>::transform are more easily deducible by the compiler.
Signed-off-by: Duarte Nunes <duarte@scylladb.com>
2.2 allows IN on any column and it seems that we support that fine, but
DTESTs except us to reject such queries.
Signed-off-by: Paweł Dziepak <pdziepak@cloudius-systems.com>
Values inside IN clause should be sorted and duplicates removed if the
restricted columns are part of the clustering key, which is always true
for multi column restrictions.
Signed-off-by: Paweł Dziepak <pdziepak@cloudius-systems.com>
range::is_wrap_around() and range::contains() rely on total ordering
on values to work properly. Current ring_position_comparator was only
imposing a weak ordering (token positions equal to all key positions
with that token).
range::before() and range::after() can't work for weak ordering. If
the bound is exclusive, we don't know if user-provided token position
is inside or outside.
Also, is_wrap_around() can't properly detect wrap around in all
cases. Consider this case:
(1) ]A; B]
(2) [A; B]
For A = (tok1) and B = (tok1, key1), (1) is a wrap around and (2) is
not. Without total ordering between A and B, range::is_wrap_around() can't
tell that.
I think the simplest soution is to define a total ordering on
ring_position by making token positions positioned either before or
after all keys with that token.
The condition is incorrect after 9b52f5bf2b.
We no longer express the full range as (min, min], and missing upper
bound as bound as (x, min] so we don't need to exclude those cases in
the check.
Origin has no notion of a maximum token so a range without upper bound
is represented as (x; min]. The splitting code is supposed to produce
only non-wrapping ranges, but (x; min] looks like a wrapping range, so
database code which consumes it would have to special-case for it. A
simpler solution is to change the splitting code to never produce a
wrapping range.
Needed to reasonably cleanly implement token restrictions.
* Fixed constness for various virtuals.
* primary_key_restrictions now inherit abstract_restriction,
similuar to Origin (for better or for worse), to avoid
duplicating attributes etc.
* primary_key_restrictions bounds & values renamed (so not to
collide with restriction), and some logic pushed downwards
(building bounds), to avoid abstraction breakage in
statement_restrictions
* primary_key_restrictions merging is now potentially replacing
to make dispatching token/multicolumn restrictions simpler
Current model was not really correct because Origin doesn't support
querying of partition ranges by their value. We can query slices
according to dht::decorated_key ordering, which orders partitions
first by token then by key value.
ring_position encapsulates range constraint. Key value is optional, in
which case only token is constrained.
To prepare a user-defined type, we need to look up its name in the keyspace.
While we get the keyspace name as an argument to prepare(), it is useless
without the database instance.
Fix the problem by passing a database reference along with the keyspace.
This precolates through the class structure, so most cql3 raw types end up
receiving this treatment.
Origin gets along without it by using a singleton. We can't do this due
to sharding (we could use a thread-local instance, but that's ugly too).
Hopefully the transition to a visitor will clean this up.
There are two sides of this optimization:
1) We don't store the length of the last component, so the
representation is now shorter.
2) A single-element tuple is serialized exactly as the component it
holds, which allows us to optimize conversions for such keys.
Holding keys and their prefixes as "bytes" is error prone. It's easy
to mix them up (or use wrong types). This change adds wrappers for
keys with accessors which are meant to make misuses as difficult as
possible.
Prefix and full keys are now distinguished. Places which assumed that
the representation is the same (it currently is) were changed not to
do so. This will allow us to introduce more compact storage for non-prefix
keys.
