#15515 closed defect (fixed)
SimpleQueryEngine doesn't correctly sort data with null [PATCH, CLA]
Reported by: | Stefan Bird | Owned by: | Kris Zyp |
---|---|---|---|
Priority: | undecided | Milestone: | 1.8 |
Component: | Data | Version: | 1.7.2 |
Keywords: | dohfail | Cc: | |
Blocked By: | Blocking: |
Description
null > "hello" == false. This means that sorting on an attribute that contains both strings and nulls will result in the rows being in an undefined order. |
Note there are other situations where this can occur but the patch doesn't deal with them for performance reasons. The situation most likely to occur is sorting numbers with NaN values, eg [{a: 5}, {a: NaN}]. Maybe a flag could be added to the sort parameter to say that NaN values may be encountered (eg {attribute: "MyNumber?", mayHaveNaN: true}).
The code in the patch considers null to be larger than any string value; this is consistent with Array.sort()'s behaviour ([null, "hello"].sort() == ["hello", null])
Attachments (1)
Change History (7)
Changed 9 years ago by
Attachment: | SimpleQueryEngine.patch added |
---|
comment:1 Changed 9 years ago by
comment:3 Changed 9 years ago by
Milestone: | tbd → 1.8 |
---|
comment:4 Changed 9 years ago by
Keywords: | dohfail added |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
[29085] breaks util/doh/runner.html?testModule=dojo.tests.store.Memory on IE8:
_AssertFailure: assertEqual() failed: expected four but got two ERROR IN: function testQueryWithSort(t){ t.is(store.query({prime: true}, {sort:[{attribute:"name"}]}).length, 3); t.is(store.query({even: true}, {sort:[{attribute:"name"}]})[1].name, "two"); t.is(store.query({even: true}, {sort:function(a, b){ return a > b ? -1 : 1; }})[1].name, "two"); t.is(store.query(null, {sort:[{attribute:"mappedTo"}]})[4].name, "four"); } FAILED test: testQueryWithSort 0 ms
Note: See
TracTickets for help on using
tickets.
fwiw, I have an override in dojo/data/util/sorter that exposes the "direction" of the sort for this reason. Currently, default sort treats nulls as "higher than any value", so they always appear at the top (or bottom if sorted descending...). I needed a behavior where nulls were always treated as "incomplete", and _always_ at the bottom regardless of sort direction. (when ascending sort, treat null as "lower than any value", descending, treat as "higher") ... slightly related to this ticket is all. Would be nice to expose the direction of the sort to the sorting function so that it could more easily handle custom considerations like this.