-
Notifications
You must be signed in to change notification settings - Fork 933
Fix NRE in linq processing of custom components #2941
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
Conversation
from x2 in session.Query<NullableOwner>() | ||
where x == x2 && x.ManyToOne == null && x.OneToOne.Name == null | ||
select x2).ToListAsync()); | ||
from x2 in session.Query<NullableOwner>() | ||
where x == x2 && x.ManyToOne == null && x.OneToOne.Name == null | ||
select x2).ToListAsync()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure why those changes occur. Let's get rid of them, if that is not an unstable generation artifact.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I just made some whitespace changes for #2772 and forgot to regenerate async code.
@@ -807,7 +819,7 @@ public void NotNhQueryableTest() | |||
Assert.That(() => expectedMemberType(memberType), $"Invalid member type: {memberType?.Name ?? "null"}"); | |||
Assert.That(() => expectedComponentType(componentType), $"Invalid component type: {componentType?.Name ?? "null"}"); | |||
|
|||
if (found) | |||
if (found && (componentType == null || componentType.PropertyNullability != null)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe instead make nullability parameter nullable. And check that _tryGetMappedNullability
returns false when it's null.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am adding a commit doing what I think you are meaning, but I do not see this as an improvement. It looks to me as a less understandable way of testing, and maybe more brittle, subject to cause the test to fail if we start implementing that nullability property for custom composite type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But with your initial change TryGetMappedNullability
call is not tested at all for problematic case. Isn't it? So your changes were not covered.
subject to cause the test to fail if we start implementing that nullability property for custom composite type.
I see no problem with adjusting existing test cases when behavior is changed.
nit: I would also add optional nullability
parameter to AssertResult
method and keep AssertResult
call it test case
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I thought the test parsing the query would also cause the method to be called, but I had not checked. I have added your nit.
from x2 in session.Query<NullableOwner>() | ||
where x == x2 && x.ManyToOne == null && x.OneToOne.Name == null | ||
select x2).ToListAsync()); | ||
from x2 in session.Query<NullableOwner>() | ||
where x == x2 && x.ManyToOne == null && x.OneToOne.Name == null | ||
select x2).ToListAsync()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I just made some whitespace changes for #2772 and forgot to regenerate async code.
To be dropped if not considered actually adequate.
fix #2937
Replace #2938.