Origin forbdis empty values in clustering key only if that clustering
key is non-composite (i.e. there is only one column).
Signed-off-by: Paweł Dziepak <pdziepak@cloudius-systems.com>
any_cast<X> is supposed to return X, but boost 1.55's any_cast<X> returns
X&&. This means the lifetime-extending construct
auto&& x = boost::any_cast<X>(...);
will not work, because the result of the expression is an rvalue reference,
not a true temporary.
Fix by using a temporary, not a lifetime-extending reference.
Fixes#163.
Encapsulate the '_values' vector to make it easier to switch the
underlying type from bytes_opt to bytes_view_opt.
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.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>
Because of the reverse flag in partition slice rows inside bounds will
be returned in reversed order, however, we still have to make sure
that the bounds are in the expected order.
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>
Values inside IN () restrictions may be either in a vector _in_values or
a marker (_in_marker or _value). To determine which one is appropriate
we check whether _in_values is empty, which is wrong because IN clause
can be empty (and there is no marker in such case). This is fixed by
using the presence of a marker to determine whether a vector of values
or a marker should be used.
Signed-off-by: Paweł Dziepak <pdziepak@cloudius-systems.com>
We need a container which can be used with compacting
allocators. "bytes" can't be used with compacting allocator because it
can't handle its external storage being moved.
Use get_storage_proxy() and get_local_storage_proxy() helpers under the
hood to simplify migration manager API users.
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
In preparation for adding listener state to migration manager, use
sharded<> for migration manager.
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Only unexpected server errors should be logged, exception classes
deriving from cassandra_exception do not count as those.
Fixes#60.
Signed-off-by: Paweł Dziepak <pdziepak@cloudius-systems.com>
INSERT statements update row marker ttl and expiry to the same values
which are set to the added/modified cells.
Signed-off-by: Paweł Dziepak <pdziepak@cloudius-systems.com>
When added to the schema and handled by legacy_schema_tables.cc, will then
appear correctly in the respective system tables.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
The statement being removed in this patch is wrong, and nonexistent in Origin.
If the list of column aliases is empty, we should leave it this way.
This code was already present before the compact storage series. But because
tables created using the schema_builder directly won't exercise this code path,
I ended up not noticing - specially because it only happens with tables that
lack a clustering key. The ones I tested through cqlsh, all had a clustering
key.
Fixes#45
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
"range::is_wrap_around() will not work with current ring_position, because it
relies on total ordering. Same for range::contains(). Currently ring_position
is weakly ordered. This series fixes this problem by making ring_position
totally ordered.
Another problem fixed by this series is handling of wrap-around ranges. In
Origin, ]x; x] is treated as a wrap around range covering whole ring."
We have the information that they should be reverted, but we are not yet
reverting them. Go ahead and do it
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
First of all, we should abide by our convention of prepending member names with
a '_'. (That is the underline character, it just looks like a face)
But more importantly, because we will be searching its contents frequently, a
helper function is provided.
Note that obviously a hash is better suited for this: but because we do need to
keep the fields in order they are inserted, a vector really is the best choice
for that.
A table is not expected to have a lot of clustering keys. So this search should
be cheap. If it turns out to be a problem, we can adjust later.
Signed-off-by: Glauber Costa <glommer@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.
