-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: Make sort stable and handle nil comparison #1094
fix: Make sort stable and handle nil comparison #1094
Conversation
I think that that is "normal" behaviour. Or maybe "expected" behaviour. I'm thinking about when I look things up on Kijiji or AutoTrader or other sites like that, if I sort prices from High to Low I get the highest price first. But if I sort prices from low to high I get the ones with no prices first and then the lowest prices. BTW the I have a solution for the detect change failure. Will open the PR for it soon. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM and the resulting behaviour is as I would expect. You can wait for other people's input if you want though.
either way we have the behavior, I suggest we should document clearly the behavior |
Agreed, any suggestions where you want that documentation to live? |
This seems really odd to me - it essentially means that nil/default is the highest value, not the lowest (as per Fred's comment). You can see this in the (modified) TestOneToManyToOneWithSumOfDeepOrderBySubTypeAndDeepOrderBySubtypeDescDirec I think it is backwards to most/(all?) sorts I have come across. Nil is usually considered to be lower/less-than than any non-nil value when sorting? With the current/proposed setup we have the below output:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the sort order is odd, and possibly misunderstood by Fred. Please dont merge until clarified/resolved. Code looks good
You're right. I thought about it wrong. For DESC we should have
And for ASC we would have
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing my approval. Sorry I had something in mind that I though was equivalent to what you had in the PR description but it was actually different. Let's revisit the order.
52dd021
to
1a59d71
Compare
@AndrewSisley Thanks for the confirmation I caught this last night as well, this fix has been pushed by handling nil comparisons properly, I remember this (somewhat indirectly) is why 2 of our tests also panic before. @fredcarle Ready for re-review with the sort handling nil like we expect. PR Description has been updated. |
Codecov Report
@@ Coverage Diff @@
## develop #1094 +/- ##
===========================================
- Coverage 67.35% 67.33% -0.02%
===========================================
Files 181 181
Lines 16730 16744 +14
===========================================
+ Hits 11268 11275 +7
- Misses 4513 4518 +5
- Partials 949 951 +2
|
1a59d71
to
fd35ebc
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - cheers for sorting this out
} | ||
|
||
testUtils.AssertPanicAndSkipChangeDetection(t, func() { executeTestCase(t, test) }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sweet :) Nice fix
"yearOpened": uint64(1999), | ||
}, | ||
}, | ||
{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
praise: Cheers for sorting this out - is horrible that we let this test into develop though, should have been flagged in review
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks for changing the behaviour and sorry again for my confusion.
…SubTypeOfBothDescAndAsc`
…epOrderBySubTypeAndDeepOrderBySubtypeAscDirections`
fd35ebc
to
ca33aa2
Compare
- Resolves #1071 - Resolves #921 - This change uses stable sort and ensures the `Less` interface implementation only returns true if the comparison is less, otherwise returns false (this is not the full story as for when we do `DESC` the less to us then is the check of if it's greater than instead of less than). Note: Ensures the ordering of the input array is preserved, so the output is always stable. - This change works on both GoLang v1.18.5 and v1.19.5. - This also resolves some nil panics we were having before (one subtask of #833, which is issue #921). 1) Fixes the test: `TestOneToManyToOneDeepOrderBySubTypeOfBothDescAndAsc` 2) Fixes the test: `TestOneToManyToOneWithSumOfDeepOrderBySubTypeAndDeepOrderBySubtypeAscDirections` - Ensures our sort handles `nil` sorting properly for `ASC` and `DESC`: ``` DESC = [10, 9, 8, ... nil, nil] ASC = [nil, nil, 1, 2, 3, ... ] ```
- Resolves sourcenetwork#1071 - Resolves sourcenetwork#921 - This change uses stable sort and ensures the `Less` interface implementation only returns true if the comparison is less, otherwise returns false (this is not the full story as for when we do `DESC` the less to us then is the check of if it's greater than instead of less than). Note: Ensures the ordering of the input array is preserved, so the output is always stable. - This change works on both GoLang v1.18.5 and v1.19.5. - This also resolves some nil panics we were having before (one subtask of sourcenetwork#833, which is issue sourcenetwork#921). 1) Fixes the test: `TestOneToManyToOneDeepOrderBySubTypeOfBothDescAndAsc` 2) Fixes the test: `TestOneToManyToOneWithSumOfDeepOrderBySubTypeAndDeepOrderBySubtypeAscDirections` - Ensures our sort handles `nil` sorting properly for `ASC` and `DESC`: ``` DESC = [10, 9, 8, ... nil, nil] ASC = [nil, nil, 1, 2, 3, ... ] ```
Relevant issue(s)
Resolves #1071
Resolves #921
Blocks: #818, #1070
Description
Less
interface implementation only returns true if the comparison is less, otherwise returns false (this is not the full story as for when we doDESC
the less to us then is the check of if it's greater than instead of less than). Note: Ensures the ordering of the input array is preserved, so the output is always stable.TestOneToManyToOneDeepOrderBySubTypeOfBothDescAndAsc
TestOneToManyToOneWithSumOfDeepOrderBySubTypeAndDeepOrderBySubtypeAscDirections
nil
sorting properly forASC
andDESC
:- This does have a side effect which is if you sort in DESC the non-sortables / defaults are sorted to the beginning.Example: LIST = 1{"x:1"}, 2{"x:2"}, *{"x:5"}, 3{"x:3"}, 2{"x:4"}
- ASC_SORTED_LIST = 1{"x:1"}, 2{"x:2"}, 2{"x:4"}, 3{"x:3"}, *{"x:5"}
- DESC_SORTED_LIST = *{"x:5"}, 3{"x:3"}, 2{"x:2"}, 2{"x:4"}, 1{"x:1"} (unsure if we want this behaviour).
More information in the issue.
Tasks
How has this been tested?
CI +
make test
Specify the platform(s) on which this was tested: