Range tombstone for a clustered row wasn't supported, so an assert
to remember that was being triggered.
Testcase was added.
Fixes#158.
Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
We are currently using the ColumnToCollectionType wrongly: we are wrapping
by that string to every collection. But that is not how Origin operates: a single
ColumnToCollectionType hosts all collections a schema has.
Funny enough, sstable2json seems to work all right without any comparator - and
that is how it worked before, but when a comparator is present, it expects it to
abide by what Origin expects. That causes us to crash.
Fixes#148
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
To avoid spreading the futures all over, we will resort to a cache with this,
the same way we did for the dc/rack information.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Only the partitioner knows how to convert a token to a sstring. Conversely,
only the partitioner can know how to convert it back.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Right now, we are converting the _data part of the token to a sstring, which
may be latter stored somewhere - in a system sstable, for instance. Later on,
we will have to get it back, but the way the code currently stands, we will get
undefined results for min and max tokens, since they have the _data field
empty.
For murmur3, strictly speaking, the correct solution would be to change
long_token to account for that. However, when we compare values, we already do
kind comparations explicitly. Inserting them there would only make that
operation branchier == costlier, which being a very common one, we don't want
to.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
This heavily used function shows up in many places in the profile (as part
of other functions), so it's worth optimizing by eliminating the special
case for the standard allocator. Use a statically allocated object instead.
(a non-thread-local object is fine since it has no data members).
"This patchset contains fixes to tuple types implementation necessary
to make them work properly. That includes using fully qualified class
name instead of CQL3 type name internally (just like it is done for
every other type), fixed bug with accessing vector that may be already
moved away and adding support for tuples in transport::type_codec."
Fixes#147.
In an expression like:
tuple_type_impl(make_name(types), std::move(types));
the order in which arguments are evaluated is unspecified and it
is possible that make_name() is called with types already moved
away.
This is fixed by using initialization list (for which order of
evalutaion is specified). Unfortunately, this also requires some code
duplication.
Signed-off-by: Paweł Dziepak <pdziepak@cloudius-systems.com>
