[SERVER-61814] How should 'numericOrdering: true' handle decimals and negatives? Created: 30/Nov/21 Updated: 06/Dec/22 Resolved: 28/Jan/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Question | Priority: | Major - P3 |
| Reporter: | David Percy | Assignee: | Backlog - Query Execution |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Assigned Teams: |
Query Execution
|
||||
| Participants: | |||||
| Description |
|
'numericOrdering: true' lets you sort strings numerically rather than lexicographically. A typical use would be something like:
Lexicographically, "10" < "9", but with 'numericOrdering: true' it treats any numeric portion of the string as a number. There can be several numbers in one string. This leads to some confusing behavior if you want to sort decimals or negative numbers:
The dot and minus sign are not interpreted as part of the number. So:
This behavior is useful for sorting version strings, where the dot is really a separator and not a decimal point. You would want "4.4.9" < "4.4.10" and "4.9" < "4.10". We should maybe document this more clearly. We could also consider adding another kind of collation, that interprets more kinds of strings numerically. |
| Comments |
| Comment by Ana Meza [ 28/Jan/22 ] |
|
As agreed during the Quick Wins Triage, we are closing this one as Won't do |
| Comment by David Percy [ 30/Nov/21 ] |
|
In the docs we could mention that our current behavior is consistent with / inherited from the collation library:
|
| Comment by David Percy [ 30/Nov/21 ] |
|
Accepting a wider variety of number-like strings opens up more questions, like:
|