[IronPython] LINQ from IronPython

Keith J. Farmer kfarmer at thuban.org
Tue Dec 22 23:22:24 CET 2009

Indeed, and Jeff demonstrates.

C# would embed such things as constant expressions or variables (as opposed to parameters), and LINQ to SQL knows to pull those in.  No problem.

As I mentioned, being able to (inasmuch as possible) mimic C# and VB's expression tree output should be the target.  Anything arcane, really, need not be supported yet.  The goal is compatibility with the more interesting providers, which were developed with those trees in mind.  This in itself doesn't preclude EF or LINQ to SQL from gaining dynamic support at a later point (although dynamic typing may), nor would it necessarily preclude being able to emit the dynamic call sites if there's nothing better (in which case, you *could* have DLR-specific APIs that consume more interesting trees).

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Jeff Hardy
Sent: Tuesday, December 22, 2009 2:12 PM
To: Discussion of IronPython
Subject: Re: [IronPython] LINQ from IronPython

On Tue, Dec 22, 2009 at 2:39 PM, Dino Viehland <dinov at microsoft.com> wrote:
> The really interesting thing to me is that this is a closure - either id is in
> a nested function scope or it's in a global scope.  I'm not sure how that gets
> transmitted across the wire.  Do closures work in LINQ in C# going across to
> a database?

    int id = 1;
    var result = customers.Where(c => c.Id == id);

would become a parametrized SQL query:
    SELECT * FROM Customers AS t0 WHERE t0.Id = @p0;

where @p0 is the parameter passed along with the query, with the value 1.

- Jeff
Users mailing list
Users at lists.ironpython.com

More information about the Ironpython-users mailing list