You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As evidenced by #5600, on occasion there may be ties in ModalLocation. As it stands, these are broken by arbitrary Postgres sort order, which can change between versions. Rather than rely on that, we should have a known and predictable tie breaker. One might be tempted to use random here, but that would actually prevent modal location queries from being parallelised, so probably better to use something else.
I think an obvious way to go here would be to extend the existing tie break logic, which uses the most recent of tied daily locations, to something like the most recent call. This would however require daily location objects to include the last included datetime. Arguably this would be to the good anyway, as we could then dispense with the slightly awkward post-attach of the corresponding date.
The text was updated successfully, but these errors were encountered:
As evidenced by #5600, on occasion there may be ties in
ModalLocation
. As it stands, these are broken by arbitrary Postgres sort order, which can change between versions. Rather than rely on that, we should have a known and predictable tie breaker. One might be tempted to userandom
here, but that would actually prevent modal location queries from being parallelised, so probably better to use something else.I think an obvious way to go here would be to extend the existing tie break logic, which uses the most recent of tied daily locations, to something like the most recent call. This would however require daily location objects to include the last included datetime. Arguably this would be to the good anyway, as we could then dispense with the slightly awkward post-attach of the corresponding date.
The text was updated successfully, but these errors were encountered: