Discriminate query plan caches by the assembly depending return type #1913
Conversation
When having multiple assemblies with the same type (this can happen when dynamically generating assemblies or loading assemblies multiple times), NHibernate used to return query plan cache entries with mismatching types. The query portion of the cache key contained the type, but not the assembly. Thus two types from different assemblies, but with the same name lead to returning plans with wrong return types.
Ablu
force-pushed
the
queryplancache-fix-sametypename-differentassembly
branch
from
5cc4e96 to
e22c516
Compare
|
Can you please add a test case? |
|
Sure. But it might take a bit until I get to it. |
|
If that helps writing the text fixture for this case here, there is already a test with dynamic assemblies here. The test for this PR should be added in the |
| { | ||
| } | ||
|
|
||
| protected HQLQueryPlanKey(System.Type queryTypeDiscriminator, string query, bool shallow, IDictionary<string, IFilter> enabledFilters) | ||
| protected HQLQueryPlanKey(System.Type queryType, System.Type queryTypeDiscriminator, string query, bool shallow, IDictionary<string, IFilter> enabledFilters) |
There was a problem hiding this comment.
I have attempted to reproduce the issue, to no avail. The query parameter was always enough to distinguish the cases, without the need of this additional queryType parameter.
I have mapped two entities having the same type name and build in different dynamic assemblies, and I have build LINQ queries on them: no troubles. The query parameter contains the entity name instead of the type name, and so they are distinguished. I had to map them with different entity names, otherwise the mapping would not compile.
I have put this test case in a PR on your branch: Ablu#1
There was a problem hiding this comment.
I have done some checks in the history, entity names were not in the query parameter before NH-2218. Was this issue reproduced with a version earlier than NH v4.1?
There was a problem hiding this comment.
The reproduction should not even require any special mappings. We hit the issues with an anonymous type (so doing from collection select new { x }), which was generated by the Roslyn scripting API. The API generates new assemblies for each evaluation. I did not test it with the very latest NH, but the bug should still occur given the code. I unfortunately have no time left this week, but I will try to take a look at it next week!
@Ablu I cherry-picked those commits and they indeed fix our problem. So you can close this PR. @fredericDelaporte Thanks for the heads up! We upgraded from 3.3 to 5.0.3 in the summer and were stuck with that version because of problems with some of our integration tests. We will investigate updating to 5.1 again when we have more time. |
|
Ah. That patch indeed looks like it should fix it (I did not realize that the string serialization of the query was generated by NHibernate, I assumed it would come somewhere from the .NET framework...). Anyway, closing this then. Sorry for the noise and thanks for the pointers! |
When having multiple assemblies with the same type (this can happen when
dynamically generating assemblies or loading assemblies multiple times),
NHibernate used to return query plan cache entries with mismatching types.
The query portion of the cache key contained the type, but not the
assembly. Thus two types from different assemblies, but with the same
name lead to returning plans with wrong return types.