…s. .NET8 when using .ToJson() Mapping vs. PostgreSQL Legacy POCO mapping

Problem was that as part of AOT refactoring we changed way that we build comparers. Specifically, comparers of collections - ListOfValueTypesComparer, ListOfNullableValueTypesComparer and ListOfReferenceTypesComparer. Before those list comparer Compare, Hashcode and Snapshot methods would take as argument element comparer, which was responsible for comparing elements.
We need to be able to express these in code for AOT but we are not able to generate constant of type ValueComparer (or ValueComparer<TElement>) that was needed. As a solution, each comparer now stores expression describing how it can be constructed, so we use that instead (as we are perfectly capable to expressing that in code form).
Problem is that now every time compare, snapshot or hashcode method is called for array type, we construct new ValueComparer for the element type. As a result in the reported case we would generate 1000s of comparers which all have to be compiled and that causes huge overhead.

Fix is to pass relevant func from the element comparer to the outer comparer. We only passed the element comparer object to the outer Compare/Hashcode/Snapshot function to call that relevant func. This way we avoid constructing redundant comparers.

Fixes #35239

…s. .NET8 when using .ToJson() Mapping vs. PostgreSQL Legacy POCO mapping

Problem was that as part of AOT refactoring we changed way that we build comparers. Specifically, comparers of collections - ListOfValueTypesComparer, ListOfNullableValueTypesComparer and ListOfReferenceTypesComparer. Before those list comparer Compare, Hashcode and Snapshot methods would take as argument element comparer, which was responsible for comparing elements. We need to be able to express these in code for AOT but we are not able to generate constant of type ValueComparer (or ValueComparer) that was needed. As a solution, each comparer now stores expression describing how it can be constructed, so we use that instead (as we are perfectly capable to expressing that in code form). Problem is that now every time compare, snapshot or hashcode method is called for array type, we construct new ValueComparer for the element type. As a result in the reported case we would generate 1000s of comparers which all have to be compiled and that causes huge overhead.

Fix is to pass relevant func from the element comparer to the outer comparer. We only passed the element comparer object to the outer Compare/Hashcode/Snapshot function to call that relevant func. This way we avoid constructing redundant comparers.

For ListOfReferenceTypesComparer it's a bit trickier - TElement of the outer comparer doesn't always match TElement of the element comparer (presumably to allow support of nested array types in the future), we we can't blindly copy over Equals/Hashcode/Snapshot method lambdas in case types are not matching. For now we check if the both type arguments match - if they do, we copy the funcs, otherwise we fallback to the old behavior, i.e. construct new element comparer so that it can deal with type argument discrepancies. We also disabled generating type mappings for nested collections. Those are not supported by EF, but we were creating mappings (and therefore comparers) for them. Weeding them out simplifies the comparer code.

Fixes #35239

…s. .NET8 when using .ToJson() Mapping vs. PostgreSQL Legacy POCO mapping

Problem was that as part of AOT refactoring we changed way that we build comparers. Specifically, comparers of collections - ListOfValueTypesComparer, ListOfNullableValueTypesComparer and ListOfReferenceTypesComparer. Before those list comparer Compare, Hashcode and Snapshot methods would take as argument element comparer, which was responsible for comparing elements. We need to be able to express these in code for AOT but we are not able to generate constant of type ValueComparer (or ValueComparer) that was needed. As a solution, each comparer now stores expression describing how it can be constructed, so we use that instead (as we are perfectly capable to expressing that in code form). Problem is that now every time compare, snapshot or hashcode method is called for array type, we construct new ValueComparer for the element type. As a result in the reported case we would generate 1000s of comparers which all have to be compiled and that causes huge overhead.

Fix is to pass relevant func from the element comparer to the outer comparer. We only passed the element comparer object to the outer Compare/Hashcode/Snapshot function to call that relevant func. This way we avoid constructing redundant comparers.

For ListOfReferenceTypesComparer it's a bit trickier - TElement of the outer comparer doesn't always match TElement of the element comparer (presumably to allow support of nested array types in the future), we we can't blindly copy over Equals/Hashcode/Snapshot method lambdas in case types are not matching. For now we check if the both type arguments match - if they do, we copy the funcs, otherwise we fallback to the old behavior, i.e. construct new element comparer so that it can deal with type argument discrepancies. We also disabled generating type mappings for nested collections. Those are not supported by EF, but we were creating mappings (and therefore comparers) for them. Weeding them out simplifies the comparer code.

Fixes #35239

…s. .NET8 when using .ToJson() Mapping vs. PostgreSQL Legacy POCO mapping

Problem was that as part of AOT refactoring we changed way that we build comparers. Specifically, comparers of collections - ListOfValueTypesComparer, ListOfNullableValueTypesComparer and ListOfReferenceTypesComparer. Before those list comparer Compare, Hashcode and Snapshot methods would take as argument element comparer, which was responsible for comparing elements. We need to be able to express these in code for AOT but we are not able to generate constant of type ValueComparer (or ValueComparer) that was needed. As a solution, each comparer now stores expression describing how it can be constructed, so we use that instead (as we are perfectly capable to expressing that in code form). Problem is that now every time compare, snapshot or hashcode method is called for array type, we construct new ValueComparer for the element type. As a result in the reported case we would generate 1000s of comparers which all have to be compiled and that causes huge overhead.

Fix is to pass relevant func from the element comparer to the outer comparer. We only passed the element comparer object to the outer Compare/Hashcode/Snapshot function to call that relevant func. This way we avoid constructing redundant comparers.

For ListOfReferenceTypesComparer it's a bit trickier - TElement of the outer comparer doesn't always match TElement of the element comparer (presumably to allow support of nested array types in the future), we we can't blindly copy over Equals/Hashcode/Snapshot method lambdas in case types are not matching. For now we check if the both type arguments match - if they do, we copy the funcs, otherwise we fallback to the old behavior, i.e. construct new element comparer so that it can deal with type argument discrepancies. We also disabled generating type mappings for nested collections. Those are not supported by EF, but we were creating mappings (and therefore comparers) for them. Weeding them out simplifies the comparer code.

Fixes #35239

…s. .NET8 when using .ToJson() Mapping vs. PostgreSQL Legacy POCO mapping

Problem was that as part of AOT refactoring we changed way that we build comparers. Specifically, comparers of collections - ListOfValueTypesComparer, ListOfNullableValueTypesComparer and ListOfReferenceTypesComparer. Before those list comparer Compare, Hashcode and Snapshot methods would take as argument element comparer, which was responsible for comparing elements. We need to be able to express these in code for AOT but we are not able to generate constant of type ValueComparer (or ValueComparer) that was needed. As a solution, each comparer now stores expression describing how it can be constructed, so we use that instead (as we are perfectly capable to expressing that in code form). Problem is that now every time compare, snapshot or hashcode method is called for array type, we construct new ValueComparer for the element type. As a result in the reported case we would generate 1000s of comparers which all have to be compiled and that causes huge overhead.

Fix is to pass relevant func from the element comparer to the outer comparer. We only passed the element comparer object to the outer Compare/Hashcode/Snapshot function to call that relevant func. This way we avoid constructing redundant comparers.

For ListOfReferenceTypesComparer it's a bit trickier - TElement of the outer comparer doesn't always match TElement of the element comparer (presumably to allow support of nested array types in the future), we we can't blindly copy over Equals/Hashcode/Snapshot method lambdas in case types are not matching. For now we check if the both type arguments match - if they do, we copy the funcs, otherwise we fallback to the old behavior, i.e. construct new element comparer so that it can deal with type argument discrepancies.

Fixes #35239

…s. .NET8 when using .ToJson() Mapping vs. PostgreSQL Legacy POCO mapping

…s. .NET8 when using .ToJson() Mapping vs. PostgreSQL Legacy POCO mapping

Problem was that as part of AOT refactoring we changed way that we build comparers. Specifically, comparers of collections - ListOfValueTypesComparer, ListOfNullableValueTypesComparer and ListOfReferenceTypesComparer. Before those list comparer Compare, Hashcode and Snapshot methods would take as argument element comparer, which was responsible for comparing elements. We need to be able to express these in code for AOT but we are not able to generate constant of type ValueComparer (or ValueComparer) that was needed. As a solution, each comparer now stores expression describing how it can be constructed, so we use that instead (as we are perfectly capable to expressing that in code form). Problem is that now every time compare, snapshot or hashcode method is called for array type, we construct new ValueComparer for the element type. As a result in the reported case we would generate 1000s of comparers which all have to be compiled and that causes huge overhead.

Fix is to pass relevant func from the element comparer to the outer comparer. We only passed the element comparer object to the outer Compare/Hashcode/Snapshot function to call that relevant func. This way we avoid constructing redundant comparers.

For ListOfReferenceTypesComparer it's a bit trickier - TElement of the outer comparer doesn't always match TElement of the element comparer. If we detect this case, we see if the lambdas (Equals, Hashcode, Snapshot) are compatible between what we expect (in the list comparer method) and what we get from the element comparer. If they are compatible we just pass the element lambda to the list method. If they are not compatible we rewrite the element lambda so that they match.

Fixes #35239

…s. .NET8 when using .ToJson() Mapping vs. PostgreSQL Legacy POCO mapping

Problem was that as part of AOT refactoring we changed way that we build comparers. Specifically, comparers of collections - ListOfValueTypesComparer, ListOfNullableValueTypesComparer and ListOfReferenceTypesComparer. Before those list comparer Compare, Hashcode and Snapshot methods would take as argument element comparer, which was responsible for comparing elements. We need to be able to express these in code for AOT but we are not able to generate constant of type ValueComparer (or ValueComparer) that was needed. As a solution, each comparer now stores expression describing how it can be constructed, so we use that instead (as we are perfectly capable to expressing that in code form). Problem is that now every time compare, snapshot or hashcode method is called for array type, we construct new ValueComparer for the element type. As a result in the reported case we would generate 1000s of comparers which all have to be compiled and that causes huge overhead.

Fix is to pass relevant func from the element comparer to the outer comparer. We only passed the element comparer object to the outer Compare/Hashcode/Snapshot function to call that relevant func. This way we avoid constructing redundant comparers.

For ListOfReferenceTypesComparer it's a bit trickier - TElement of the outer comparer doesn't always match TElement of the element comparer. If we detect this case, we see if the lambdas (Equals, Hashcode, Snapshot) are compatible between what we expect (in the list comparer method) and what we get from the element comparer. If they are compatible we just pass the element lambda to the list method. If they are not compatible we rewrite the element lambda so that they match.

Fixes #35239

…s. .NET8 when using .ToJson() Mapping vs. PostgreSQL Legacy POCO mapping

Problem was that as part of AOT refactoring we changed way that we build comparers. Specifically, comparers of collections - ListOfValueTypesComparer, ListOfNullableValueTypesComparer and ListOfReferenceTypesComparer. Before those list comparer Compare, Hashcode and Snapshot methods would take as argument element comparer, which was responsible for comparing elements. We need to be able to express these in code for AOT but we are not able to generate constant of type ValueComparer (or ValueComparer) that was needed. As a solution, each comparer now stores expression describing how it can be constructed, so we use that instead (as we are perfectly capable to expressing that in code form). Problem is that now every time compare, snapshot or hashcode method is called for array type, we construct new ValueComparer for the element type. As a result in the reported case we would generate 1000s of comparers which all have to be compiled and that causes huge overhead.

Fix is to pass relevant func from the element comparer to the outer comparer. We only passed the element comparer object to the outer Compare/Hashcode/Snapshot function to call that relevant func. This way we avoid constructing redundant comparers.

For ListOfReferenceTypesComparer it's a bit trickier - TElement of the outer comparer doesn't always match TElement of the element comparer. If we detect this case, we see if the lambdas (Equals, Hashcode, Snapshot) are compatible between what we expect (in the list comparer method) and what we get from the element comparer. If they are compatible we just pass the element lambda to the list method. If they are not compatible we rewrite the element lambda so that they match.

Fixes #35239

…s. .NET8 when using .ToJson() Mapping vs. PostgreSQL Legacy POCO mapping

Problem was that as part of AOT refactoring we changed way that we build comparers. Specifically, comparers of collections - ListOfValueTypesComparer, ListOfNullableValueTypesComparer and ListOfReferenceTypesComparer. Before those list comparer Compare, Hashcode and Snapshot methods would take as argument element comparer, which was responsible for comparing elements. We need to be able to express these in code for AOT but we are not able to generate constant of type ValueComparer (or ValueComparer) that was needed. As a solution, each comparer now stores expression describing how it can be constructed, so we use that instead (as we are perfectly capable to expressing that in code form). Problem is that now every time compare, snapshot or hashcode method is called for array type, we construct new ValueComparer for the element type. As a result in the reported case we would generate 1000s of comparers which all have to be compiled and that causes huge overhead.

Fix is to pass relevant func from the element comparer to the outer comparer. We only passed the element comparer object to the outer Compare/Hashcode/Snapshot function to call that relevant func. This way we avoid constructing redundant comparers.

For ListOfReferenceTypesComparer it's a bit trickier - TElement of the outer comparer doesn't always match TElement of the element comparer. If we detect this case, we see if the lambdas (Equals, Hashcode, Snapshot) are compatible between what we expect (in the list comparer method) and what we get from the element comparer. If they are compatible we just pass the element lambda to the list method. If they are not compatible we rewrite the element lambda so that they match.

Fixes #35239

…s. .NET8 when using .ToJson() Mapping vs. PostgreSQL Legacy POCO mapping

…s. .NET8 when using .ToJson() Mapping vs. PostgreSQL Legacy POCO mapping

Problem was that as part of AOT refactoring we changed way that we build comparers. Specifically, comparers of collections - ListOfValueTypesComparer, ListOfNullableValueTypesComparer and ListOfReferenceTypesComparer. Before those list comparer Compare, Hashcode and Snapshot methods would take as argument element comparer, which was responsible for comparing elements. We need to be able to express these in code for AOT but we are not able to generate constant of type ValueComparer (or ValueComparer) that was needed. As a solution, each comparer now stores expression describing how it can be constructed, so we use that instead (as we are perfectly capable to expressing that in code form). Problem is that now every time compare, snapshot or hashcode method is called for array type, we construct new ValueComparer for the element type. As a result in the reported case we would generate 1000s of comparers which all have to be compiled and that causes huge overhead.

Fix is to pass relevant func from the element comparer to the outer comparer. We only passed the element comparer object to the outer Compare/Hashcode/Snapshot function to call that relevant func. This way we avoid constructing redundant comparers.

For ListOfReferenceTypesComparer it's a bit trickier - TElement of the outer comparer doesn't always match TElement of the element comparer. If we detect this case, we see if the lambdas (Equals, Hashcode, Snapshot) are compatible between what we expect (in the list comparer method) and what we get from the element comparer. If they are compatible we just pass the element lambda to the list method. If they are not compatible we rewrite the element lambda so that they match.

Fixes #35239

refactored into ConvertingValueComparer

…s. .NET8 when using .ToJson() Mapping vs. PostgreSQL Legacy POCO mapping

Problem was that as part of AOT refactoring we changed way that we build comparers. Specifically, comparers of collections - ListOfValueTypesComparer, ListOfNullableValueTypesComparer and ListOfReferenceTypesComparer. Before those list comparer Compare, Hashcode and Snapshot methods would take as argument element comparer, which was responsible for comparing elements. We need to be able to express these in code for AOT but we are not able to generate constant of type ValueComparer (or ValueComparer) that was needed. As a solution, each comparer now stores expression describing how it can be constructed, so we use that instead (as we are perfectly capable to expressing that in code form). Problem is that now every time compare, snapshot or hashcode method is called for array type, we construct new ValueComparer for the element type. As a result in the reported case we would generate 1000s of comparers which all have to be compiled and that causes huge overhead.

Fix is to pass relevant func from the element comparer to the outer comparer. We only passed the element comparer object to the outer Compare/Hashcode/Snapshot function to call that relevant func. This way we avoid constructing redundant comparers.

In order to do that safely we need to make sure that type of the element comparer and the type on the list comparer are compatible (so that when func from element comparer is passed to the list comparer Equals/Hashcode/Snapshot method the resulting expression is valid. We do that by introducing a comparer that converts from one type to another, so that they are always aligned.

Fixes #35239