We're updating the issue view to help you get more done. 

Incorrect QueryModel for multiple Selects

Description

I'm trying to create my own query processor. Unless I'm doing something wrong, there seem to be a bug in ReLinq that produces a bad QueryModel from a simple LINQ expression.

My test case is this:

The first part is nothing fancy, just the entry point into my own LINQ provider.
The crucial part for the bug is that I have two Select calls.

When debugging, my QueryableBase ctor is called correctly, first for the Table, then with a .Select call expression, then again on top of that with the second .Select call expression.

But then the QueryModel that my QueryModelVisitorBase receives is wrong.
Specifically:
its SelectClause is the last one (okay, makes sense)...
that contains a multiply expression...
whose left side is a Id member...
whose source is the MainFromClause, i.e. the Sql.Table() call.

That last bit is wrong! x in the second Select is not a Customer!
It's the anonymous type produced by the first Select.

Activity

Show:
User known
January 3, 2019, 10:20 PM

Ooh.... I see. Thanks for your insight.

It's mostly that my test case was failing because I did not expect this behavior and it looked wrong to me, but that optimization is correct so the end result of my query processor would be correct (optimized, even).

Let me check a less trivial case and if it looks ok then I'll close this bug.

Michael Ketting
January 4, 2019, 9:38 AM

Great to hear, thanks. When you are closing it, please select "won't fix" as the reason in the drop down.

User known
January 7, 2019, 9:12 PM

So I was wary of being able to produce bad Select elision because of either:

  • a difference between the semantics of C# and the target domain;

  • functions call that have a very special meaning for my query processor.

At this stage of development I could not create any such bug.

Moreover double-select is not idiomatic for the query processor I'm writing, it was rather something I wanted to detect and throw an error rather than support. So if someone does something stupid with above mentionned functions, well I can just say it's not supported.

I'm closing this, thanks for the support!

User known
January 7, 2019, 9:14 PM

@Michael.Ketting Sorry it seems I'm not able to close the issue myself. Please feel free to do so.

Michael Ketting
January 8, 2019, 6:48 AM

thanks for the update. Yeah, even with Linq there will always be some gap between those. See C# let-clause vs it's (non-existent) SQL equivalent. As for closing, yeah, looks like it's restricted to project developers

Assignee

Michael Ketting

Reporter

User known

Labels

None

Components

Fix versions

Affects versions

Priority

Normal
Configure