Discrepancy with leveldown re "end" vs "lte" and "lt"

[rvagg]

@timoxley noticed this, I'm just reporting the details: if you compare leveldown to memdown you find a discrepancy if you provide both a lte or lt property and an end property for an iterator. Obviously this isn't something you should really be doing but it's not out of the realms of possibility that someone would want to provide these properties together.

memdown treats the lte and lt as authoratative, overriding whatever end says, while leveldown takes the minimum of the options.

Compare: https://github.com/dominictarr/ltgt/blob/master/index.js#L50-L56 (lowerBound but same logic applies for upperBound I think, it's just clearer here) to https://github.com/Level/leveldown/blob/master/src/iterator.cc#L141-L153

This is something that we should resolve in AbstractLevelDOWN tests I think.

[rvagg]

updated to s/gt/lt

[dominictarr]

given that end is now considered legacy and lt is the recommended api it should use lt first, and end if it's not available. or better, we could remove end from leveldown c and map end to lte in leveldown javascript?

[rvagg]

yeah, I'm +1 on that, after I filed this issue I realised that ltgt was probably "right" and it was actually a leveldown issue that should have been filed