We can insert markers in the end of composites, which can be used to identify
the presence of ranges in a column.
One option, would be to change all methods in sstables/key.hh to take an
optional marker parameter, and append that as the last marker.
But because we are talking about a single byte, and always added to the end,
it's a lot easier to allow the composite to be created normally, and then
replace the last byte with the marker.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Tomek got confused with the fact that we had to pass bytes_type for this code
to work. And well, that's understandable: that code evolved quite a bit since
its first user, and now the interface is not quite the best for the job,
forcing us to employ weird tricks like that for the code to work.
In this cleanup, I am creating a serializer object, that will encode
information about how to serialize the component passed. In the majority of the
cases, a simple sstable_serializer will just serialize to itself - accepting as
parameters byte_views.
In the case we need to operate on a deeply exploded view - the only case for
which we truly needed types, the respective serializer will take a types vector
and use it accordingly.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Encapsulating it into a composite class is a more natural way to handle this,
and will allow for extending that class later.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Composites have an extra byte at the end of each element. The middle bytes
are expected to be zero, but the last one may not always be. In cases like
those of a range tombstone, we will have a marker with special significance.
Since we are exploding the composite into its components, we don't actually
need to retrieve it. We merely need to make sure that the marker is the one
we expect.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Read mutations from sstables, from Glauber.
Conflicts:
sstables/key.cc
sstables/key.hh
sstables/sstables.cc
sstables/sstables.hh
[avi: adjust sstables/partition.cc:149 for ambiguity due to new
basic_sstring range constructor]
from_components() is made more generic so as to be re-used for
the creation of a composite from a clustering_key.
Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
Reviewed-by: Nadav Har'El <nyh@cloudius-systems.com>
Use decorated_key in partition maps, from Tomasz:
"Partitions should be ordered using Origin's ordering, which is the natural
ordering of decorated_key. This is achieved by switching column_family's
partition map to use decorated_key instead of a bare partition_key.
This also includes some cleanups."
[avi] trivial adjustments to sstables/keys.cc
We have our own representation of a partition_key, clustering_key, etc. They
may different slightly from a legacy sstable key because we don't necessarily
serialize composites in our internal representation the same way as Origin
does. This patch encodes the Origin composite serialization, so we can create
keys that are compatible with Origin's understanding of what a partition key
should look like.
This whould be used when serializing or deserializing to/from an sstable.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
