-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Breaking Change in 8.0.4: System.InvalidOperationException: The data is NULL at ordinal 0. This method can't be called on NULL values. Check using IsDBNull before calling. #33547
Comments
I see that Microsoft.EntityFrameworkCore 8.0.4 is now "unlisted": Is that because of this issue? Note that a couple of v8.0.4 packages are still listed, with a reference to Microsoft.EntityFrameworkCore 8.0.4, but they will fail to install or update. IMHO it would be better if all dependent packages would also be unlisted in such a situation. |
Agreed. More importantly to us, where can we find information on why this package was unlisted? Should we hold off on upgrading to 8.0.4? Can we safely use Microsoft.EntityFrameworkCore/8.0.3 with other packages such as Microsoft.EntityFrameworkCore.Relational/8.0.4? |
@PjotrB @dougclutter 8.0.4 is back up. Unlisting was not intentional, likely a glitch in our system. We are looking into the details, what exactly happened, but it should be safe to upgrade. |
#32911 is the culprit. @eisbaer66 - you can make your scenario work on 8.0.4 by setting the following AppContext switch: |
Problem is that upon applying LEFT JOIN operation, Enum value on the complex type is not marked as nullable. We have StructuralTypeProjectionExpression and we mark all the primitive properties as nullable, but for nested structures (like the complex type here) we only mark the shaper itself nullable, but the nested StructuralTypeProjectionExpression that is stored in the ValueBufferExpression is not touched. In 8.0.3 we were storing all the properties of complex types in the flat structure, along with regular properties, so the nullabilities were set for all of them. |
Can confirm that setting |
…ption: The data is NULL at ordinal 0. This method can't be called on NULL values. Check using IsDBNull before calling. Problem was that we changed the way that we store complex type information in the StructuralTypeProjectionExpression, specifically after performing pushdown. We used to extract all the properties from complex types into a flat list, along with regular properties, but that was wrong - we need to uphold the nested structure. If that STPE with flattened structure would be made nullable, we go through all the properties and mark the column expressions as nullable (which included properties of a complex type). However, in the new regime, we were not making those changes to columns representing complex type in the nested structure. As a result, if those columns were later projected (after pushdown), they would seem to be non-nullable, and could cause errors. Fix is, during MakeNullable() operation for a complex type StructuralTypeProjectionExpression, to peek inside it's ValueBufferExpression and mark all the columns found there as nullable. Fixes #33547
…ption: The data is NULL at ordinal 0. This method can't be called on NULL values. Check using IsDBNull before calling. Problem was that we changed the way that we store complex type information in the StructuralTypeProjectionExpression, specifically after performing pushdown. We used to extract all the properties from complex types into a flat list, along with regular properties, but that was wrong - we need to uphold the nested structure. If that STPE with flattened structure would be made nullable, we go through all the properties and mark the column expressions as nullable (which included properties of a complex type). However, in the new regime, we were not making those changes to columns representing complex type in the nested structure. As a result, if those columns were later projected (after pushdown), they would seem to be non-nullable, and could cause errors. Fix is, during MakeNullable() operation for a complex type StructuralTypeProjectionExpression, to peek inside it's ValueBufferExpression and mark all the columns found there as nullable. Fixes #33547
…ption: The data is NULL at ordinal 0. This method can't be called on NULL values. Check using IsDBNull before calling. (#33559) Problem was that we changed the way that we store complex type information in the StructuralTypeProjectionExpression, specifically after performing pushdown. We used to extract all the properties from complex types into a flat list, along with regular properties, but that was wrong - we need to uphold the nested structure. If that STPE with flattened structure would be made nullable, we go through all the properties and mark the column expressions as nullable (which included properties of a complex type). However, in the new regime, we were not making those changes to columns representing complex type in the nested structure. As a result, if those columns were later projected (after pushdown), they would seem to be non-nullable, and could cause errors. Fix is, during MakeNullable() operation for a complex type StructuralTypeProjectionExpression, to peek inside it's ValueBufferExpression and mark all the columns found there as nullable. Fixes #33547
reopening for patch |
…ption: The data is NULL at ordinal 0. This method can't be called on NULL values. Check using IsDBNull before calling. Problem was that we changed the way that we store complex type information in the StructuralTypeProjectionExpression, specifically after performing pushdown. We used to extract all the properties from complex types into a flat list, along with regular properties, but that was wrong - we need to uphold the nested structure. If that STPE with flattened structure would be made nullable, we go through all the properties and mark the column expressions as nullable (which included properties of a complex type). However, in the new regime, we were not making those changes to columns representing complex type in the nested structure. As a result, if those columns were later projected (after pushdown), they would seem to be non-nullable, and could cause errors. Fix is, during MakeNullable() operation for a complex type StructuralTypeProjectionExpression, to peek inside it's ValueBufferExpression and mark all the columns found there as nullable. Fixes #33547
…ption: The data is NULL at ordinal 0. This method can't be called on NULL values. Check using IsDBNull before calling. (#33692) Problem was that we changed the way that we store complex type information in the StructuralTypeProjectionExpression, specifically after performing pushdown. We used to extract all the properties from complex types into a flat list, along with regular properties, but that was wrong - we need to uphold the nested structure. If that STPE with flattened structure would be made nullable, we go through all the properties and mark the column expressions as nullable (which included properties of a complex type). However, in the new regime, we were not making those changes to columns representing complex type in the nested structure. As a result, if those columns were later projected (after pushdown), they would seem to be non-nullable, and could cause errors. Fix is, during MakeNullable() operation for a complex type StructuralTypeProjectionExpression, to peek inside it's ValueBufferExpression and mark all the columns found there as nullable. Fixes #33547
merged for 8.0.6 in #33692, closing |
File a bug
I have run into this problem when upgrading from 8.0.3 to 8.0.4.
I have a Parent type that contains an optional Child.
The Child contains a simple type, that is saved as a ComplexProperty.
There is a QueryFilter defined for the Child (simple bool property "Deleted").
The Complex type contains a
enum
.When I now try to query the enum coming from the Parent type though the Child and Complex types, I want the result to be
null
, if the (optional) Child is not set (isnull
).But i get a InvalidOperationException instead.
Downgrading back to 8.0.3 restores the expected behavior again.
Include your code
I have created a small solution with one console project to reproduce the problem:
efcore-enum-in-optional-complex-property-with-queryfilter-repro.zip
It creates a sqlite database (deleting any existing "test.db" file beforehand) so you should be able to just run it (again and again) to reproduce the exception.
Stack traces
Include provider and version information
EF Core version: 8.0.4 (still works in 8.0.3)
Database provider: Microsoft.EntityFrameworkCore.Sqlite 8.0.4 (same error happens with Microsoft.EntityFrameworkCore.SqlServer 8.0.4)
Target framework: .NET 8.0
Operating system: Windows 11
IDE: Visual Studio 2022 17.9.5
The text was updated successfully, but these errors were encountered: