Invalid Reverse Iterator Seek Test

[VannaDii]

Invalid Reverse Iterator Seek Test

[VannaDii]

Ahhh, I see now. Thank you for that explanation. This might be a good explanation to add to the iterator documentation? I'll close this issue. Sorry for the trouble.

[vweevers]

The limit applies to the total number of items retrieved, not to what's on disk. It does a seek first, then from it where landed, retrieves items until the limit is reached.

[vweevers]

Following LevelDB logic, forwards seeks land on the target, or the key after it. In reverse mode, we reversed that logic: a backwards seek lands on the target or the key before it.

[VannaDii]

@vweevers that makes sense, however, it also makes assumption 1 - items are stored in the order received. It seems problematic to impose this storage rule on the underlying persistence layer, no?

Also, in this case, the key provided to seek doesn't exist at all, it was never put.

[vweevers]

Also, in this case, the key provided to seek doesn't exist at all, it was never put.

I'll rephrase: seeks land on the target or - if that key does not exist - the key after/before it.

Items are sorted lexicographically. In this case, the inserted keys one, two, three sort as one, three, two. If you imagine the key three! in between them, they sort as one, three, three!, two. Seeking backwards to three! would land on three! if that key existed, but it doesn't, so it lands on three.

[vweevers]

No trouble at all.

[VannaDii]

Wait, but doesn't limit: 1 mean that only two would be retrieved in reverse landing the seek on undefined?