November Happy Hour will be moved to Thursday December 5th.
November Happy Hour will be moved to Thursday December 5th.
I would think that is because Code field is of type string - assuming you are talking about Code property on a catalog item.
That should still work, right?
But regardless, I have tried with decimal and int with the same result.
I tried to OrderBy date and that seems to work.
With decmial I get:
query.OrderBy(arg => arg.ListPrice());
[0]: 169.99 [1]: 349.95 [2]: 398.65 [3]: 424.92 [4]: 509.15 [5]: 594.15 [6]: 644.3 [7]: 696.15 [8]: 823.65 [9]: 1184.97 [10]: 2899.99 [11]: 143.4 [12]: 220.15 [13]: 229.46 [14]: 237.15 [15]: 277.1 [16]: 299.99 [17]: 313.65 [18]: 325.51 [19]: 499.99 [20]: 509.15 [21]: 526.15 [22]: 577.15 [23]: 1104.15
Got curious - did a test using Find v. 12.5.3 ( see results below). So you are right, should still work. Would file it as a bug in v. 13.0.1
By code:
10003556
10004299
10109080
10114122
10156933
10156958
10156966
10156974
10156982
10157113
10168110
10168128
10168136
10168151
10168177
10168193
10168268
10168276
10168284
10168292
I down graded to Find v. 12.7.1 and it works.
Have now reported it to support.episerver.com
Update: I uppgraded to Episerver.Commerce 12 and now the Ordering works... though I don't know why this effected ordering for Find.
Yes. It did upgrade EPiServer.Find.Commerce from v. 10.2.0 to v. 11.0.0 as well.
Hi,
Jakob did you get any answer to that from support?
It seems we have just hit into same issues with searching. For us searching by date does not work as well. Originally I thought it is just DateTime type but then realized that sorting also by other string properties added to page types does not work at all when running Find 13 (or it makes sorting somehow fragmented just like you described).
Sorting WORKS on default fields like StartPublish or Name.
I have confirmed that also trying on Alloy site.
After downgrading to version 12.7.1 it is working again, is there any bug registered by support already? and when we could expect fixing?
Br, Greg
Hi Grzegorz,
I got it to work by upgrading Episerver.Commerce to 12 and Episerver marked my ticket as solved.
I don't think they should have done that as the reason for the issue is still unknown, but as it started working for me I didn't continue with the ticket.
Well we do not run Commerce and similar issue is there, I created ticket for that as well
Great! Come back with any updates as I'm (and maybe others) still interested in why this happens.
We're investigating this again.
When reproducing this we also see that it is working when downgrading from 13.01 to 12.7.1 but we also notice that it continues to work after upgrading back to 13.0.1.
We're trying to figure out why this is.
Thanks
Daniel Dahlin, Developer Support
This has been confirmed to be a bug in Find 13.01. Bug FIND-3596.
When testing locally this seems to be a possible workaround
.OrderBy(arg => arg.Code, null, null, false);
Hi
Fresh info about bug from support (thanks Daniel)
Hi Grzegorz, This bug is fixed. When it's due for release it should appear here. https://world.episerver.com/support/Bug-list/bug/FIND-3596
Just wanted to bump this, as we have seen issues with orderby as well. We were able to get around the issue using the solution posted by dada.
Sorry for late comment. I also created a late blog post for this issue https://world.episerver.com/blogs/Son-Do/Dates/2018/7/sorting-issue-in-episerver-find-13-0-1/.
This issue will be released pretty soon after Find service is upgraded.
Regards,
/Son Do
Hi, I have a strange problem ocuring when I try to use OrderBy for any given propery: The ordering is fragmented.
What I mean by that is if I OrderBy on number I get something like: 1, 2, 5, 6, 3, 4, 7, 8, 0 and then 6, 5, 2, 1, 8, 7, 4, 3, 0 for descending. It seams like the result is getting orderd by something else before ordering on the number, but I have triple-checked the request and there is only one sort object in the sort array.
Gives:
And
Gives:
I have tried switching indexes and still the issue remains.
I'm using Episerver.Find 13.0.1.