Open bromike opened 1 month ago
Thanks for reporting this. Seems like the new way to combine primary key values for the cache key don't work correctly for non-numeric ID's. I'll look into it.
Are your ID's actually 11111111-1111-1111-1111-111111111111
, 22222222-2222-2222-2222-222222222222
and 33333333-3333-3333-3333-333333333333
? Because their hash codes are all 0
. However I'd suspect that this would lead to flaky mapping before, since that logic also used the hash code.
Are your ID's actually 11111111-1111-1111-1111-111111111111, 22222222-2222-2222-2222-222222222222 and 33333333-3333-3333-3333-333333333333? Because their hash codes are all 0. However I'd suspect that this would lead to flaky mapping before, since that logic also used the hash code.
Not always, these were some examples but they are also usually generated via Guid.NewGuid()
in the context of unit tests.
I can't reproduce the issue with actual generated GUID's (eg Guid.NewGuid()
). Do you have an example of that?
From 3.3.2 to 3.3.3, we noticed that some queries became flaky and started failing, at some times where it seemed random.
We are mostly using queries similar to:
We noticed that sometimes, it would wrongly map element tags to an element. It would return this:
Rather than returning tags according to their ElementKeyIds:
However, looking at the logs from Dommel, It would actually print out the proper query in the logs:
It is very flaky, sometimes it will work, sometimes not. So I'm not sure if it's related to how it works with the cache key, but this actually blocks the upgrade. There is no issue on 3.3.2