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.
"This is my current proposal for Compact Storage tables - plus
the needed infrastructure.
Getting rid of the CellName abstraction allows us to simplify
things by quite a lot: now all we need is to mark whether or
not a table is composite, and provide functions to play the
role of the comparator when dealing with the strings."
"These patches fix more problems related to ORDER BY clauses.
Firstly, mutation_partition::query() can now return rows in reveresed
order which makes it easy for select statements to ask for data from
single partition with clustering keys in reversed order even if limit
of rows is set.
That alone is not sufficient, though, if the request contains IN clause
on partition keys and number of returned rows is limited. The information
needed to determine which rows need to be in the reply isn't available
before post-query sort is done, so select statement asks for more rows
than the limit and trims the output later."
"The following patches fix a bug in collections setters where the tombstone
was created but never applied if the collection was set to null.
This series makes cql_tests.py:TestCQL.null_support_test pass."
This is how Java does. But in C++, "throw new", although valid, would require
the catcher to catch a pointer to the exception - which isn't really what we
do.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
We currently have code to calculate "is_dense" in the create statement handler.
That obviously don't work for the system schemas, which are not defined this
way.
Since all of our schemas now have to pass through the schema_builder one way or
another, that is the best place in which to do that calculation.
Note that unfortunately, that does not mean we can just get rid of
set_is_dense() in the schema builder: we still need to set it in some
situations, where for instance, we read that property in schema_columnfamilies,
and then apply to the relevant CF. Those uses are, however, all internal to
legacy_schema_tables.cc
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
In case of queries with IN on partition key, ORDER BY and LIMIT it is
not known until after post-query sort which rows should be included in
the result set. To make sure that the output is correct each partition
specified in IN clause is queried for LIMIT rows and the excess data is
trimmed after the results are sorted.
Signed-off-by: Paweł Dziepak <pdziepak@cloudius-systems.com>
When partition_slice option reversed is set the query will already
return rows in desired (i.e. reversed) order. That's not true, however,
for statements using IN restriction on partition keys. In such case
post-query ordering is still needed.
Signed-off-by: Paweł Dziepak <pdziepak@cloudius-systems.com>
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.
Before this patch the tombstone created in setter::execute() was never
applied if the new collection value was null.
Signed-off-by: Paweł Dziepak <pdziepak@cloudius-systems.com>
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.
