Optional feature to list keys or iterate through them

[wking]

For example, content-addressable-store has all, and go-datastore has KeyList. You'll need some way to iterate through your storage if you want to garbage-collect dangling references or have external corruption-checking processes.

For large stores, you'll probably want something that you can iterate through. For example, Elasticsearch has from and size, Redis has LRANGE key start stop, and S3 has marker and max-keys.

[max-mapper]

I was thinking about taking a stab at an abstract-table-store module, something like abstract-leveldown but less leveldb specific (less surface area). The idea being you could make all leveldown modules compatible with the abstract-table API but you could also write basic table API wrappers around databases that are harder to implement leveldown on top of

[wking]

On Sun, Nov 09, 2014 at 03:48:14AM -0800, Max Ogden wrote:

I was thinking about taking a stab at an abstract-table-store module, …

Sounds great, but I still think you'll want a way for the blob storage to iterate over its keys. You could keep track of the blob keys in a table-store, but then you'd have no way to recover from corruption or crashes that left index and blob store out of sync.