Lexicographic sorting in name_scan

[yanmaani]

name_scan sorts numerically: if I search for d/roanapu, I'll get d/roanoke (8 chars) first, not d/roanapur (9 chars).

This is nonlexicographic. The reason for is that LevelDB by default indexes on (length || string), so d/roanapur is internally something like \x09d/roanapur.

It would be possible to have LevelDB use a custom comparator, but it might be some work. If that is not acceptable, you'd have to implement custom logic:

1. Lock
2. Find first name exceeding search string, (search string || \x00), (search string || \x00\x00), ... into a list
3. Sort list
4. Yield first element of list
5. Replace such with second name exceeding its search string
6. Go to 3 unless done
7. Unlock

This could then be selected by a flag in the options object, another advantage to forcing it across the index database.

[domob1812]

This is indeed true. But as you point out, it would at least be non-trivial to change (although also not impossible). What would be the benefit? I think name_scan should in principle just be used to iterate names from a script or something, and probably not even guarantee a particular sorting order (to give implementations the freedom to do precisely things like this as is most suitable).

[yanmaani]

The benefit is that autocomplete-style systems could be implemented in an easier fashion, without having to keep a finicky second index of names.

Making a fixed guarantee that it uses a specific, known sort order if some option is passed should be more than enough, as then applications could rely on that. (i.e. undefined if no option, numeric if that specific option, no other options supported)

I don't think Bitcoin are going to move away from LevelDB soon, and if they are, it should be trivial while moving over the database to make it use "Nd/myname" as keys instead.