Grouped exceptions should use the latest/most recent date

[cottsak]

Correct me if I'm wrong, but it seems that when exceptions are grouped, the date (for ordering the item in the list) is taken from the first occurrence of the grouped exception. This seems odd to me and I find myself getting frustrated when I trigger an exception (manually for example), and find that it's not at the top of the list, but rather a few lines down but now with a (2).

I would have thought that like a grouped email thread, that when a new message (or exception) is added to the thread/group, that then the whole group would then be considered new/recent and move to the top of the list.

Is it by design that the last/most recent item in a group is not the one whose date is used for sorting?

[NickCraver]

This issue here is that there's no LatestDate column in the SQL provider (the hardest to change/upgrade). In retrospect I should have added it, we discussed this internally after a year of use...is it worth the upgrade pain for others caused by adding it though? That's the piece I'm not so sure about.

[cottsak]

What do you mean by "is it worth the upgrade pain for others"? Are you saying that maybe the cost of upgrading to a newer version to get this feature (if you add it) outweighs the value from the feature?

[NickCraver]

What I mean is it's a scheme change in SQL, so it's a breaking scheme change, not just a NuGet update. That means it has to be in a major version release and won't be automatic/easy for most people. You have to keep in mind that many people using tis don't have control over their production environments, and there's a whole change control process in play. I'll take a look at making it work with the old and new scheme...that would be the only viable option I see, detected once on app start...let me peek at it later today then update this.

[cottsak]

Perhaps you could add the date for all providers except the SQL one? This way, the in-memory and json providers would have the feature (proper sorting) and the SQL one would not. You could add a TODO to fix the SQL schema for the major release and the rest of us could get the value now. Thoughts?

[NickCraver]

This will be going into 2.0. I'm hoping to get a 2.0 (CoreCLR compatible) version out in the next month or two.

[cottsak]

Nice

[NickCraver]

Added in V2! There will be schema changes to accommodate this (we need a new column), but it's for the greater good. The scripts are now idempotent for setting up and upgrading to the latest version though.

[cottsak]

Available in .NET 4.5?

[NickCraver]

Yep v2 should support net45 and netstandard2.0