-
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
NumberToBytesConverter on ulong RowVersion property fails with .Include query #12518
Comments
Notes for triage:
Broken query log:
|
doing a cleanup of my repos. can u take a copy of what u need from https://github.com/SimonCropp/EfRowVersionRepro/ so i can delete it |
@SimonCropp I think we have what we need. |
@ajcvickers cool. thanks for the followup |
ah man I hit this too, looking forward to a fix |
Providing a temporary workaround that worked in my case: on this table:
using this builder config:
manually changing the default value to a non-zero length array in the migration fixes it:
|
@ajcvickers - Where is NumberToBytesConverter? |
This is working in 3.1 |
The bug is the following. In the BufferedDataReader.BufferedDataRecord.ReadRow method the following check is performed Modifying the QueryBugsTest.Projecting_entity_with_value_converter_and_include_works test from |
You have the following options:
Let me know what you decide. |
Note--in the bug filed here there are no child rows in the table, and hence we should never be reading the row with an empty rowversion. This seems like the critical part to figure out before deciding how to fix the issue. |
@ajcvickers If you are going with option 3, you will have to always include the primary key columns in every outer join query for it to work. SELECT TOP(1) [c].[Id], [c].[ULongRowVersion]
FROM [Parents] AS [p]
LEFT JOIN [Children] AS [c] ON [p].[ChildId] = [c].[Id] Or alternatively translate to SELECT TOP(1) CASE WHEN [c].[Id] IS NULL THEN CAST(1 AS BIT) ELSE CAST(0 AS BIT) END AS [IsNull], [c].[ULongRowVersion]
FROM [Parents] AS [p]
LEFT JOIN [Children] AS [c] ON [p].[ChildId] = [c].[Id] |
I am having this issue in 5.0.4. I can't seem to figure out if the bug was fixed (can't find a commit in here that addresses the issue). |
@billybraga If this isn't working for you with 5.0.4, then please open a new issue and attach a small, runnable project or post a small, runnable code listing that reproduces what you are seeing so that we can investigate. |
@ajcvickers Done #24446 |
Sorry about the detail. but this has a few moving pieces.
(TLDR run this test in the repro)
Scenario
ulong
property with a NumberToBytesConverter.HasConversion(new NumberToBytesConverter<ulong>())
.ULongRowVersion
to a rowversionFirstOrDefault
query onParent
and.Include
theChild
propertyOutcome
InvalidOperationException
in NumberToBytesConverter.ReverseLong.The strange thing is, that with my understanding of the above scenario,
NumberToBytesConverter
should never be called since there are no rows in that table.Repro
https://github.com/SimonCropp/EfRowVersionRepro
The above failing scenario is in the ULongRowVersionContext and can be executed in the Tests.ULongRowVersion() method.
There are also two other working scenarios.
Using BytesRowVersion
This scenario still uses a
ulong
for the row version, but with a custom. ULongRowVersionWithWorkAroundContext and can be executed in the Tests.ULongRowVersionWithWorkAround() method.ULongToBytesConverter is a clone of NumberToBytesConverter. When debugging the exception was occurring in the code generated by the custom expressions, so it made it very difficult to understand what the problem was. When i initially created ULongToBytesConverter i got the same exception as with NumberToBytesConverter. But since i was able to debug i was able to see where the error was occurring and add a workaround.
Note that i have no idea why this works ;)
Further technical details
The text was updated successfully, but these errors were encountered: