Skip to content
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

Query :: some queries with Queryable.Cast<T> don't work #3736

Closed
maumar opened this issue Nov 12, 2015 · 4 comments
Closed

Query :: some queries with Queryable.Cast<T> don't work #3736

maumar opened this issue Nov 12, 2015 · 4 comments
Assignees
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-bug
Milestone

Comments

@maumar
Copy link
Contributor

maumar commented Nov 12, 2015

Repro:

var query = from Post p in ctx.Posts
            select p.PostId;

var result = query.ToList();

the compiler introduces a Cast() (because type of "p" has been explicitly specified) relinq turns this into a subquery like so:

from p in  { from p' in ctx.Post select p' => Cast<Post>() } select p.PostId

then we lift the subquery:

from p in ctx.Posts select p.PostId => Cast<Post>()

this fails with the following:

Unhandled Exception: System.InvalidOperationException: No coercion operator is defined between types 'System.Int32' and 'Repro3499.Post'.
at System.Linq.Expressions.Expression.GetUserDefinedCoercionOrThrow(ExpressionType coercionType, Expression expression, Type convertToType)
at System.Linq.Expressions.Expression.Convert(Expression expression, Type type, MethodInfo method)
at Remotion.Linq.Clauses.ResultOperators.CastResultOperator.GetOutputDataInfo(IStreamedDataInfo inputInfo)
at Remotion.Linq.QueryModel.b__0(IStreamedDataInfo current, ResultOperatorBase resultOperator)
at System.Linq.Enumerable.Aggregate[TSource,TAccumulate](IEnumerable1 source, TAccumulate seed, Func3 func)
at Remotion.Linq.QueryModel.GetOutputDataInfo()
at Microsoft.Data.Entity.Query.EntityQueryModelVisitor.SingleResultToSequence(QueryModel queryModel) in D:\k\EntityFramework\src\EntityFramework.Core\Query\EntityQueryModelVisitor.cs:line 249
at Microsoft.Data.Entity.Query.EntityQueryModelVisitor.CreateQueryExecutor[TResult](QueryModel queryModel) in D:\k\EntityFramework\src\EntityFramework.Core\Query\EntityQueryModelVisitor.cs:line 163
at Microsoft.Data.Entity.Storage.Database.CompileQuery[TResult](QueryModel queryModel) in D:\k\EntityFramework\src\EntityFramework.Core\Storage\Database.cs:line 68
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
at Microsoft.Data.Entity.Query.Internal.QueryCompiler.<>c__DisplayClass19_01.<CompileQuery>b__0() in D:\k\EntityFramework\src\EntityFramework.Core\Query\Internal\QueryCompiler.cs:line 183 at Microsoft.Data.Entity.Query.Internal.CompiledQueryCache.GetOrAddQuery[TResult](Object cacheKey, Func1 compiler) in D:\k\EntityFramework\src\EntityFramework.Core\Query\Internal\CompiledQueryCache.cs:line 32
at Microsoft.Data.Entity.Query.Internal.QueryCompiler.CompileQuery[TResult](Expression query) in D:\k\EntityFramework\src\EntityFramework.Core\Query\Internal\QueryCompiler.cs:line 138
at Microsoft.Data.Entity.Query.Internal.QueryCompiler.Execute[TResult](Expression query) in D:\k\EntityFramework\src\EntityFramework.Core\Query\Internal\QueryCompiler.cs:line 84
at Microsoft.Data.Entity.Query.Internal.EntityQueryProvider.Execute[TResult](Expression expression) in D:\k\EntityFramework\src\EntityFramework.Core\Query\Internal\EntityQueryProvider.cs:line 37
at Remotion.Linq.QueryableBase1.GetEnumerator() at System.Collections.Generic.List1..ctor(IEnumerable`1 collection)

In this case the cast is redundant, but if we project a property from a derived type like so:

from VipCustomer c in ctx.Customers
select c.SomeVipCustomerProperty

the cast needs to be preserved

@mikary
Copy link
Contributor

mikary commented Apr 27, 2016

Verified that this is still an issue. May be related to / relevant for #4875

@smitpatel
Copy link
Contributor

@maumar - This is somewhat related to our discussion from today.

@maumar
Copy link
Contributor Author

maumar commented Apr 28, 2017

it might also be due to incorrect assumption in the QM lifting, i.e. lifting casts is not always safe

maumar added a commit that referenced this issue Apr 29, 2017
Problem was that during optimization, when we flatten subqueries we didn't account for Cast result operator properly. This would fail when trying to access a property on a derived type, when derived type was coming from a subquery with Cast result operator.

Fix is to wrap qsres to that (former) subquery with Convert to the last type that the subquery was casted into (in case multiple cast operators are used).

Also fixed another issue around this area:

- We tried to lift Distinct in some cases, which could lead to incorrect results. E.g

from outer in (ctx.Customers.Distinct())
select outer.Name

would get translated to:

(from outer in ctx.Customers
select outer.Name).Distinct()
maumar added a commit that referenced this issue Apr 29, 2017
Problem was that during optimization, when we flatten subqueries we didn't account for Cast result operator properly. This would fail when trying to access a property on a derived type, when derived type was coming from a subquery with Cast result operator.
Fix is to wrap qsres to that (former) subquery with Convert(s) the subquery was casted into.

Also fixed another issue around this area:

We tried to lift Distinct in some cases, which could lead to incorrect results. E.g

from outer in (ctx.Customers.Distinct())
select outer.Name

would get translated to:

(from outer in ctx.Customers
select outer.Name).Distinct()
maumar added a commit that referenced this issue Apr 29, 2017
Problem was that during optimization, when we flatten subqueries we didn't account for Cast result operator properly. This would fail when trying to access a property on a derived type, when derived type was coming from a subquery with Cast result operator.
Fix is to wrap qsres to that (former) subquery with Convert(s) the subquery was casted into.

Also fixed another issue around this area:

We tried to lift Distinct in some cases, which could lead to incorrect results. E.g

from outer in (ctx.Customers.Distinct())
select outer.Name

would get translated to:

(from outer in ctx.Customers
select outer.Name).Distinct()
maumar added a commit that referenced this issue Apr 29, 2017
Problem was that during optimization, when we flatten subqueries we didn't account for Cast result operator properly. This would fail when trying to access a property on a derived type, when derived type was coming from a subquery with Cast result operator.
Fix is to wrap qsres to that (former) subquery with Convert(s) the subquery was casted into.

Also fixed another issue around this area:

We tried to lift Distinct in some cases, which could lead to incorrect results. E.g

from outer in (ctx.Customers.Distinct())
select outer.Name

would get translated to:

(from outer in ctx.Customers
select outer.Name).Distinct()
maumar added a commit that referenced this issue Apr 29, 2017
Problem was that during optimization, when we flatten subqueries we didn't account for Cast result operator properly. This would fail when trying to access a property on a derived type, when derived type was coming from a subquery with Cast result operator.
Fix is to wrap qsres to that (former) subquery with Convert(s) the subquery was casted into.

Also fixed another issue around this area:

We tried to lift Distinct in some cases, which could lead to incorrect results. E.g

from outer in (ctx.Customers.Distinct())
select outer.Name

would get translated to:

(from outer in ctx.Customers
select outer.Name).Distinct()
maumar added a commit that referenced this issue Apr 29, 2017
Problem was that during optimization, when we flatten subqueries we didn't account for Cast result operator properly. This would fail when trying to access a property on a derived type, when derived type was coming from a subquery with Cast result operator.
Fix is to wrap qsres to that (former) subquery with Convert(s) the subquery was casted into.

Also fixed another issue around this area:

We tried to lift Distinct in some cases, which could lead to incorrect results. E.g

from outer in (ctx.Customers.Distinct())
select outer.Name

would get translated to:

(from outer in ctx.Customers
select outer.Name).Distinct()
maumar added a commit that referenced this issue Apr 29, 2017
Problem was that during optimization, when we flatten subqueries we didn't account for Cast result operator properly. This would fail when trying to access a property on a derived type, when derived type was coming from a subquery with Cast result operator.
Fix is to wrap qsres to that (former) subquery with Convert(s) the subquery was casted into.

Also fixed another issue around this area:

We tried to lift Distinct in some cases, which could lead to incorrect results. E.g

from outer in (ctx.Customers.Distinct())
select outer.Name

would get translated to:

(from outer in ctx.Customers
select outer.Name).Distinct()
maumar added a commit that referenced this issue May 1, 2017
Problem was that during optimization, when we flatten subqueries we didn't account for Cast result operator properly. This would fail when trying to access a property on a derived type, when derived type was coming from a subquery with Cast result operator.
Fix is to wrap qsres to that (former) subquery with Convert(s) the subquery was casted into.

Also fixed another issue around this area:

We tried to lift Distinct in some cases, which could lead to incorrect results. E.g

from outer in (ctx.Customers.Distinct())
select outer.Name

would get translated to:

(from outer in ctx.Customers
select outer.Name).Distinct()
maumar added a commit that referenced this issue May 1, 2017
Problem was that during optimization, when we flatten subqueries we didn't account for Cast result operator properly. This would fail when trying to access a property on a derived type, when derived type was coming from a subquery with Cast result operator.
Fix is to wrap qsres to that (former) subquery with Convert(s) the subquery was casted into.

Also fixed another issue around this area:

We tried to lift Distinct in some cases, which could lead to incorrect results. E.g

from outer in (ctx.Customers.Distinct())
select outer.Name

would get translated to:

(from outer in ctx.Customers
select outer.Name).Distinct()
maumar added a commit that referenced this issue May 2, 2017
Problem was that during optimization, when we flatten subqueries we didn't account for Cast result operator properly. This would fail when trying to access a property on a derived type, when derived type was coming from a subquery with Cast result operator.
Fix is to wrap qsres to that (former) subquery with Convert(s) the subquery was casted into.

Also fixed another issue around this area:

We tried to lift Distinct in some cases, which could lead to incorrect results. E.g

from outer in (ctx.Customers.Distinct())
select outer.Name

would get translated to:

(from outer in ctx.Customers
select outer.Name).Distinct()
maumar added a commit that referenced this issue May 4, 2017
Problem was that during optimization, when we flatten subqueries we didn't account for Cast result operator properly. This would fail when trying to access a property on a derived type, when derived type was coming from a subquery with Cast result operator.
Fix is to wrap qsres to that (former) subquery with Convert(s) the subquery was casted into.

Also fixed another issue around this area:

We tried to lift Distinct in some cases, which could lead to incorrect results. E.g

from outer in (ctx.Customers.Distinct())
select outer.Name

would get translated to:

(from outer in ctx.Customers
select outer.Name).Distinct()
@maumar
Copy link
Contributor Author

maumar commented May 4, 2017

Fixed in aacb31f

@maumar maumar closed this as completed May 4, 2017
@maumar maumar added the closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. label May 4, 2017
@bricelam bricelam modified the milestones: 2.0.0, 2.0.0-preview2 May 16, 2017
@ajcvickers ajcvickers modified the milestones: 2.0.0-preview2, 2.0.0 Oct 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-fixed The issue has been fixed and is/will be included in the release indicated by the issue milestone. type-bug
Projects
None yet
Development

No branches or pull requests

6 participants