The column_name can be comprised of more than one element. This will
be the case for collections, that will embed part of the collection
data in the column name.
While doing this, we also take advantage of the infrastructure we have
added to composite. We are duplicating this logic unnecessarily, which
is prone to bugs. Those bugs are not just theoretical in this case: we
are not writing the final marker for empty composite keys.
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>
Make sure keyspace exists for all test cases, not just ones that call
the create_table() helper.
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
Before sealing an sstable, here's what we have to do, filter-wise:
1) determine wether or not we should have a filter file. We won't write
one, if our fp_chance is 1.0,
2) add each index key to the filter,
3) and write the actual filter.
This patch implements those steps.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Store a lw_shared_ptr<keyspace_metadata> in struct keyspace so callers
in migration manager, for example, can look it up.
Signed-off-by: Pekka Enberg <penberg@cloudius-systems.com>
While trying to write code to populate the system table's data, I found out
that currently, there is no publicly exported way for an entity outside the
sstable to find out which are the keys available in the index.
Without the full list of keys, it is very hard to make the kind of
"read-everything" queries we will need for that to work.
Although I haven't checked the internals fully, Origin seems to do that through
token-based range searches, where you can specify start and end tokens and
return everything in the middle (this is how the WHERE clauses are
implemented).
I am proposing in this patchset a subscription interface that will allow us
to extract data from the sstables in this fashion.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
The current code for position determination works well if we are in the
last summary group. For the ones in the middle, it won't.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
The readability improvements alone justify it, but on top of that, I would like
to reuse this one.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
It would be helpful to sometimes avoid passing a key parameter from the
consumer, since we not always know what to expect. In those situations, we can
easily construct it from the data we see in consume_row_start.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
This is my turn to make the same mistake as Nadav recently made: I have
written down the expected position from the test output itself, instead
of checking the file.
A position of 0x400c0000000000 is obviously ridiculous. The file itself is not
that big. My recent patch to fix the summary broke the test, and so we need to
fix it.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Since that whole entries array is memory mapped, we should not call
read_integer - which will byteswap it.
We should instead just fetch the position directly.
This was not spotted before because our test sstables tend to be relatively
small.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
Currently if you run more than one instance on the same machine, they
all bind to the same local address and port (we enable an option that
makes this non error) and cql/thrift requests are distributed randomly
among them.
Some urchin parameters has default value of localhost and need to be
resolved into IP address. Add stub resolver that do just that: if it
sees "localhost" string it translates it to a loopback address,
otherwise assume that string is IP address already.
Java uses long, so we should use int64_t. Using uint64_t causes the wrong
indexes to be calculated, and therefore, the filter to respond incorrectly
to a given key.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
I actually wrote this code before I learned that we could just return a local
vector by copy without major hassles.
Never too late for a cleanup.
Signed-off-by: Glauber Costa <glommer@cloudius-systems.com>
This patch is built on the previous one, where access to members of sstable
class was made possible.
Index file is being properly generated, but it's important mentioning that
promoted indexes aren't supported yet.
Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>
The function write_datafile was renamed to write_components and made a member
of sstable class because write of components requires access to private
members. This change is an important step towards the generation of components
other than data file.
The respective testcases were adapted to the changes.
Signed-off-by: Raphael S. Carvalho <raphaelsc@cloudius-systems.com>