Files
scylladb/tests
Nadav Har'El d42c05b6ad sstable: Pull-style read interface
This patch replaces the sstable read APIs from having "push" style,
to having "pull style".

The sstable read code has two APIs:
 1. An API for sequentially consuming low-level sstable items - sstable
    row's beginning and end, cells, tombstones, etc.
 2. An API for sequentially consuming entire sstable rows in our "mutation"
    format.

Before this patch, both APIs were in "push style": The user supplies
callback functions, and the sstable read code "pushes" to these functions
the desired items (low-level sstable parts, or whole mutations).
However, a push API is very inconvenient for users, like the query
processing code, or the compaction code, which both iterate over mutations.
Such code wants to control its own progression through the iteration -
the user prefers to "pull" the next mutation when it wants it; Moreover,
the user wants to *stop* pulling more mutations if it wants, without
worrying about various continuations that are still scheduled in the
background (the latter concern was especially problematic in the "push"
design).

The modified APIs are:

1. The functions for iterating over mutations, sstable::read_rows() et al.,
   now return a "mutation_reader" object which can be used for iterating
   over the mutation: mutation_reader::read() asks for the next mutation,
   and returns a future to it (or an unassigned value on EOF).
   You can see an example on how it is used in sstable_mutation_test.cc.

2. The functions for consuming low-level sstable items (row begin, cell,
   etc.) are still partially push-style - the items are still fed into
   the consume object - but consumpton now *stops* (instead of defering
   and continuing later, as in the old code) when the consumer asks to.
   The caller can resume the consumption later when it wishes to (in
   this sense, this is a "pull" API, because the user asks for more
   input when it wants to).

This patch does *not* remove input_stream's feature of a consumer
function returning a non-ready future. However, this feature is no longer
used anywhere in our code - the new sstable reader code stops the
consumption when old sstable reader code paused it temporarily with
a non-ready future.

Signed-off-by: Nadav Har'El <nyh@cloudius-systems.com>
2015-06-03 10:55:34 +03:00
..
2015-06-03 10:55:34 +03:00
2015-03-06 10:06:16 +02:00
2015-06-03 10:01:00 +03:00
2015-05-19 19:33:18 +03:00
2015-03-22 16:16:30 +02:00
2015-03-04 17:40:58 +02:00
2015-05-17 15:57:11 +03:00