Query: Navigation rewrite does not preserve the type of result #15535
Assignees
Labels
closed-fixed
The issue has been fixed and is/will be included in the release indicated by the issue milestone.
customer-reported
type-bug
Milestone
Comments
maumar
added a commit
that referenced
this issue
Jun 4, 2019
…of result Problem was that we were only storing generic method definition for cardinality reducing operators (First/Single) because nav rewrite changes source types a lot. However, those operators are applied after pending selector, so they are guaranteed to be of the same type as originally. We only need to track the changes that happen e.g. during member pushdown, e.g.: customers.FirstOrDefault<Customer>().Id is changed to customers.Select(c => c.Id).FirstOrDefault<int>()
maumar
added a commit
that referenced
this issue
Jun 4, 2019
…of result Problem was that we were only storing generic method definition for cardinality reducing operators (First/Single) because nav rewrite changes source types a lot. However, those operators are applied after pending selector, so they are guaranteed to be of the same type as originally. We only need to track the changes that happen e.g. during member pushdown, e.g.: customers.FirstOrDefault<Customer>().Id is changed to customers.Select(c => c.Id).FirstOrDefault<int>()
maumar
added a commit
that referenced
this issue
Jun 4, 2019
…of result Problem was that we were only storing generic method definition for cardinality reducing operators (First/Single) because nav rewrite changes source types a lot. However, those operators are applied after pending selector, so they are guaranteed to be of the same type as originally. We only need to track the changes that happen e.g. during member pushdown, e.g.: customers.FirstOrDefault<Customer>().Id is changed to customers.Select(c => c.Id).FirstOrDefault<int>()
maumar
added a commit
that referenced
this issue
Jun 5, 2019
…of result Problem was that we were only storing generic method definition for cardinality reducing operators (First/Single) because nav rewrite changes source types a lot. However, those operators are applied after pending selector, so they are guaranteed to be of the same type as originally. We only need to track the changes that happen e.g. during member pushdown, e.g.: customers.FirstOrDefault<Customer>().Id is changed to customers.Select(c => c.Id).FirstOrDefault<int>()
|
fixed in db9bca3 |
maumar
added
the
closed-fixed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Failing test
FindSqlServerTestNonGeneric.Find_base_type_using_derived_set_tracked_async
When we do FindAsync, we generate
FirstOrDefault<object>, That information has to be flown to translation pipeline so our final result is of typeTask<object>(Our Async contract just takes TResult now). Nav expansion is eating up that type somehow so our final result is of typeTask<DerivedType>which cannot be used to returnTask<object>. (This works for sync because of implicit casting).The text was updated successfully, but these errors were encountered: