Question: Iteration order + sorting

Nobody has claimed this yet.

Hey all,

I have a quick question that might betray my ignorance about HyperDB internals. I'm starting to build out a CouchDB-style indexing system on top of HyperDB, and I'm trying to figure out if there's a way to use the underlying HAMT without having to build a secondary index (a B-tree) on top of it.

Pretty sure that thought boils down to one of iteration order. I notice in the current master, results are [sorted based on path hash](https://github.com/mafintosh/hyperdb/blob/b099a375cb8ef1b6f48fa53de385c73ad0aebfe3/lib/iterator.js#L265). Does the path hashing that's used to construct the prefix trie make it impossible to do an efficient ranged iteration over keys in pre-hash lexicographic order (a la LevelDB)?

If so, does this represent a fundamental limitation on building LevelDB-style applications on HyperDB without adding an additional level of indexing? If that's the case, would designating certain path ranges as non-hashable (make the prefix trie out of the actual path values) completely break the data structure, or would it only make it less scalable, as the trie would no longer be uniformly distributed?

Hope that's not too much! I'm trying to gauge my options before pushing forward with Plan B-Tree.

Start with lib/iterator.js around line 265, where results are described as sorted by path hash, and trace the HAMT and prefix-trie iteration behavior. Compare that behavior with the requested pre-hash lexicographic range iteration and examine how non-hashed path ranges would affect the data structure. Done would mean a documented feasibility conclusion about ranged iteration and secondary indexing.

Written by the indexing model from the issue text.