Store.tableIterator()
provides non-atomic table iteration.
Store.tableIterator()
does not return the entire set of rows all at once. Instead, it
batches the fetching of rows in the iterator, to minimize the
number of network round trips, while not monopolizing the
available bandwidth. Also, the rows returned by this method are
in unsorted order.
Note that this method does not result in a single atomic operation. Because the retrieval is batched, the return set can change over the course of the entire retrieval operation. As a result, you lose the atomicity of the operation when you use this method.
This method provides for an unsorted traversal of rows in your table. If you do not provide a key, then this method will iterate over all of the table's rows.
When using this method, you can optionally specify:
A FieldRange
object, which
defines a range of values to be retrieved for the
specified key.
A list of parent and ancestor tables to include in the iteration.
A ReadOptions
object,
which allows you to specify a consistency policy for
the operation, as well as an upper bound on the amount
of time that the operation is allowed to take.
Consistency policies are described in
Consistency Guarantees
An iteration direction. FORWARD
and
REVERSE
are supported.
For example, suppose you have a table that stores information about products, which is designed like this:
CREATE TABLE myTable ( itemType STRING, itemCategory STRING, itemClass STRING, itemColor STRING, itemSize STRING, price FLOAT, inventoryCount INTEGER, PRIMARY KEY (SHARD(itemType, itemCategory, itemClass), itemColor, itemSize) )
With tables containing data like this:
Row 1:
itemType: Hats |
itemCategory: baseball |
itemClass: longbill |
itemColor: red |
itemSize: small |
price: 12.07 |
inventoryCount: 127 |
Row 2:
itemType: Hats |
itemCategory: baseball |
itemClass: longbill |
itemColor: red |
itemSize: medium |
price: 13.07 |
inventoryCount: 201 |
Row 3:
itemType: Hats |
itemCategory: baseball |
itemClass: longbill |
itemColor: red |
itemSize: large |
price: 14.07 |
inventoryCount: 39 |
Row n:
itemType: Coats |
itemCategory: Casual |
itemClass: Winter |
itemColor: red |
itemSize: large |
price: 247.99 |
inventoryCount: 9 |
Then in the simplest case, you can retrieve all of the rows
related to 'Hats' using
Store.tableIterator()
as follows. Note that this simple example can also be accomplished using
the
Store.multiGet()
method. If you have a complete shard key, and if the entire
results set will fit in memory, then
multiGet()
will perform much better than
tableIterator()
.
However, if the results set cannot fit entirely in memory, or
if you do not have a complete shard key, then
tableIterator()
is the better choice. Note that reads performed using
tableIterator()
are non-atomic, which may have ramifications if you are
performing a long-running iteration over records that are being
updated.
... // Store handle configuration and open skipped for brevity ... // Open the store with the specified configuration var store = nosqldb.createStore(configuration); store.on('open', function () { console.log('Store opened'); var key = {itemType: "Hats"}; store.tableIterator('myTable', key, null, function (err, iterator) { if (err) throw err; else { // Configure Iterator event done iterator.on('done', function() { store.close(); }); console.log("Retrieved rows:"); iterator.forEach(function (err, returnRow) { if (err) throw err; else console.log(returnRow.row); console.log('\n'); }); } }); }).on('close', function() { console.log('Store closed.'); }).on('error', function(error) { console.log(error); }); store.open();