The multi-part identifier "LPA_L2.TradeId" could not be bound
Joined: 02-May-2012
Joined: 02-May-2012
Evan wrote:
What's very unlikely? You think I fabricated the error?
I am using a version pulled from nuget, but I suppose I could upgrade the designer. Seems unrelated though. In my experience minor updates to designer haven't had hugely impacted the generated code.
Please use the versions of the runtime that's the same as the version of the designer and the generated code. What you're doing isn't supported, as we need to be able to change things across versions (and we do that actually). It might 'work' but it's not guaranteed.
That said, your issue isn't caused by that but likely by the fact the from x in ... syntaxis results in a different SelectMany() call (another overload) than the one you're using in the direct call to SelectMany(). SelectMany is a nasty method to support in a linq provider, so we went for the one that's generated by the compilers. I have to check, but I think that's the cause. (The overload with projectors is key). It loses track indeed with sources where they come from if things aren't matching what the compilers generate, as it's sometimes impossible to do. (Consider using a custom class for the projection in a Join() call: what property matches which ctor argument so it's possible to track its source back (so the right alias can be assigned)? that's usually the root of things going off the cliff in linq providers 
I wish I could solve that but it's caused by the design of how linq expression trees work and the linq API)
Your 'join' using query isn't technically equivalent to the selectmany call btw: a SelectMany() is in general a cross join, however if it detects a navigation it will try to convert it into an outer join as that's in general the intend. So in this case it results in the same sql, but doesn't have to in general. If you want to do an outer join and not a cross join, don't use SelectMany.
Your initial query works by moving a ')' to a different spot:
tempQueryable = tradeQueryable.GravitateSecurityContextFilter(gravitateSecurityContext).SelectMany(t => t.TradeDetails).Select(td => td.Product);
This works, because it can reason about the element that select many works on and moves the projection outside the selectmany.
A typical query with selectmany using 'normal' linq syntax is using 2 from clauses, so in your case that would be:
tempQueryable = from t in tradeQueryable.GravitateSecurityContextFilter(gravitateSecurityContext)
from td in tradeDetailQueryable
where t.TradeId equals td.TradeId
select td.Product;
or
tempQueryable = from t in tradeQueryable.GravitateSecurityContextFilter(gravitateSecurityContext)
from td in t.TradeDetails
select td.Product;
Using these you'll see if you enable tracing, it will use a different SelectMany() overload, namely the one with a projection. This is required as it tells the provider what projection is used to create the joined set from the sequence.
Another one, which is equal to what the 'normal' linq sequence creates, is this one:
tempQueryable = tradeQueryable.GravitateSecurityContextFilter(gravitateSecurityContext).SelectMany(t => t.TradeDetails, (t, td)=>td.Product);
This also creates the most efficient query as it knows how to navigate and it realizes it can use a relationship.
Join, SelectMany, they need to have a projection lambda as second argument. The overload you're using leads to less stellar results 
Hope this helps
Joined: 02-May-2012
Joined: 02-May-2012
aaahhh now I see 
The newer code was refactored to be more compact if I recall correctly (have to lookup the change in svn), the original method is called by the (de)setupSync method.
In v5.4 this is all moved to the base class so this is no more in the generated code, in v5.3 it's still there indeed.