How to resolve constant object property reference in DLinq expression

  • Thread starter Thread starter Andrus
  • Start date Start date
A

Andrus

The following code fails:

CompaniesDetails c2 = (from c in db.CompaniesDetails where c.CompanyID
== comp.ID select c).Single();

"comp" is an instance of class Company:

public class Company
{
public int ID;
{
get;
set;
}

DLinq provider does not know what comp is in runtime.
So compiler must replace comp.ID with value when creating expression.
Any idea how to fix this ?

Andrus.
 
Andrus said:
The following code fails:

CompaniesDetails c2 = (from c in db.CompaniesDetails where c.CompanyID
== comp.ID select c).Single();

"comp" is an instance of class Company:

public class Company
{
public int ID;
{
get;
set;
}

DLinq provider does not know what comp is in runtime.
So compiler must replace comp.ID with value when creating expression.
Click to expand...

No, the *compiler* doesn't have to do that at all. The *compiler* will
just be calling

db.CompaniesDetails.Where(c => c.CompanyID == comp.ID)

So, it's up to Where to understand the expression tree. If the DLinq
provider doesn't understand it, that sounds like a bug in DLinq to me.
 
No, the *compiler* doesn't have to do that at all. The *compiler* will
just be calling

db.CompaniesDetails.Where(c => c.CompanyID == comp.ID)

So, it's up to Where to understand the expression tree. If the DLinq
provider doesn't understand it, that sounds like a bug in DLinq to me.
Click to expand...

Provider gets string "comp.ID".
Lets assume that comp is local object name.
Provider does not have access to method local name table to resolve name
"comp".
As far as I know local variable names like "comp" are not stored in
assembly and Linq does not pass such table to provider.

So provider cannot resolve the name "comp" in any way.

Andrus.
 
Andrus said:
Provider gets string "comp.ID".
Click to expand...

No, the provider will get an expression tree, not a string, unless
something has already converted it into a string - which it certainly
shouldn't have done.

Put it this way - the compiler works exactly the same way with LINQ to
SQL, so do you believe *that* handles it? This is certainly an issue
with DbLINQ, *not* with the C# compiler.
 
Jon,
Put it this way - the compiler works exactly the same way with LINQ to
SQL, so do you believe *that* handles it? This is certainly an issue
with DbLINQ, *not* with the C# compiler.
Click to expand...

So you can confirm, that Linq-SQL can evaluate this expression, right ?
If So I must study passed expression tree a bit more.

Where to find some Linq provider sample code which resolves local object
references line comp.ID to values?

Andrus.
 
Andrus said:
So you can confirm, that Linq-SQL can evaluate this expression, right ?
Click to expand...

It's as easy for you to try as it is for me - easier, as you know the
real context of your code. However, I've certainly done similar things
without any problem.

However, I can certainly confirm that the expression tree *won't* just
contain "comp.ID" as a string.
If So I must study passed expression tree a bit more.
Where to find some Linq provider sample code which resolves local object
references line comp.ID to values?
Click to expand...

I think you'll find it simple when you look at the actual expression
tree.
 
Back
Top