Linq; expression parser?

[Marc Gravell]

The only way this can work IMHO is that they create

propertydescriptor
instances upfront in the tree which refer to Value1, correct?

Pretty much... actually, it uses a PropertyInfo; I don't know enough
about LINQ (yet) to know whether this is the only way... there is also
an overload of Expression.Property() that accepts the name, but
presumably this would then be less bound. I haven't tried reading the
IL to see what is going on in each overload.

Marc

 

[Frans Bouma [C# MVP]]

Pretty much... actually, it uses a PropertyInfo; I don't know enough
about LINQ (yet) to know whether this is the only way... there is
also an overload of Expression.Property() that accepts the name, but
presumably this would then be less bound. I haven't tried reading the
IL to see what is going on in each overload.

Ok, so this is then indeed usable in Linq to Object scenario's where
property descriptors can be used to filter objects. Using a tree with
property info/descriptor objects to generate SQL is a different thing
IMHO as the descriptor of the field doesn't tell you to which element
it belongs to. So "CustomerID == 'CHOPS'" is a valid filter for Order
but also for Customer. Having both in a query gives a bit of a problem
to which element you refer: customer or order

I haven't checked out the string output in detail for an expression
tree which represents a full 'from ... where select' query. Are you
looking for a parser of these kind of queries or just single predicate
-> tree fragment ?

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[Marc Gravell]

The code in the sample doc also includes Select etc support, but my
main question really related to filters (partly due to trying to solve
a specific problem). Since this was (broadly) comparable to some of
the LINQ features, I thought I'd investigate what (if any) overlap
existed. In short, I was after a parser for a string filter, that
could spit out a delegate. I took a stab in the dark that LINQ might
offer this as a bi-product. I wasn't far off...

But the sample code may be of use/interest to other devs.

As for your other questions (on the "why")... In this instance, yes: I
did have a specific intent in mind - but I was also motivated by
finding out more about LINQ, what is possible, what isn't, etc. Surely
that understanding is key in knowing when a new technology might be
useful...? And LINQ seems such a change that the more understanding we
have in the community, the better.

 

[Marc Gravell]

See also another reply a few minutes ago.

err, why would someone need a parser for that if it ISN'T about
roundtripping?

How about cross-architecture? As an "off the cuff", how about a
web-service that allowed me to issue a LINQ expression (in a known
scope)? And if the caller isn't .Net, or doesn't have shared assembly
access?

All I'm sayinng is that:
* LINQ has rich support for qualified queries
* (unrelated) Sometimes, you need to express a query between layers,
systems, or architectures, and a textual form is the lowest common
denominator
* So wouldn't it be nice if LINQ could bridge this gap, using *an*
expression syntax (not necessarily C#), which could be parsed into
proper expression trees

As a person who writes query consuming code for a living, I do
understand the necessity for dynamic queries build at runtime, but
using strings for that isn't the answer

I'll remember that next time I'm writing SQL ;-p

Marc

 

[Frans Bouma [C# MVP]]

How about cross-architecture? As an "off the cuff", how about a
web-service that allowed me to issue a LINQ expression (in a known
scope)? And if the caller isn't .Net, or doesn't have shared assembly
access?

That's IMHO a bad way of doing SOA. The webservice should be autonome,
have its own interface (methods) and work on a high level of your
application stack. So you send it messages, not filters.

All I'm sayinng is that:
* LINQ has rich support for qualified queries
* (unrelated) Sometimes, you need to express a query between layers,
systems, or architectures, and a textual form is the lowest common
denominator * So wouldn't it be nice if LINQ could bridge this gap,
using an expression syntax (not necessarily C#), which could be
parsed into proper expression trees

That sounds great on paper, but as I said in the quote below: queries
in strings aren't maintainable and often break at runtime. You need a
typed, compile time checked query language which, if an error is
specified, breaks at compile time so you can fix it before you ship it
to the customer

I'll remember that next time I'm writing SQL ;-p

Marc, you're still using EXEC sp_executeSQL "query" ?

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[Marc Gravell]

That's IMHO a bad way of doing SOA.

Yes - I did say it was "off the cuff"... but I'm still of the opinion
that string-based runtime queries still have a role to play in
some scenarios. It shouldn't be the default, but there seems
to be enough interest to at least not preclude it.

You need a typed, compile time checked query language which,
if an error is specified, breaks at compile time so you can fix
it before you ship it to the customer

In a perfect world, yes. But inevitably some things can't be known
at compile-time. It happens.

Marc, you're still using EXEC sp_executeSQL "query" ?

A bit OT, but if I had the need to write dynamic SQL *inside* the
database (not from C#), then yes: sp_executeSQL on a
parameterised nvarchar query would be the correct solution.

But equally - yes, sometimes it is necessary to build up an SQL
query manually (parameterised of course), beyond what most ORMs
will offer (e.g. a current project involves a fully-temporal database
implementation; I've not had much luck using ORM in such
scenarios - perhaps yours is better the others, I don't know).
OR-mappers (including D-LINQ) aren't the only code that can
write SQL.

Marc

 

[Frans Bouma [C# MVP]]

Yes - I did say it was "off the cuff"... but I'm still of the opinion
that string-based runtime queries still have a role to play in
some scenarios. It shouldn't be the default, but there seems
to be enough interest to at least not preclude it.

the only reason I heard in the past years which makes some sense (not
much, but some) is that a string based query language often looks
similar to SQL.

In a perfect world, yes. But inevitably some things can't be known
at compile-time. It happens.

I haven't ran into these situations where you couldn't construct the
object based query at runtime and had to revert to stored strings.

A bit OT, but if I had the need to write dynamic SQL inside the
database (not from C#), then yes: sp_executeSQL on a
parameterised nvarchar query would be the correct solution.

But equally - yes, sometimes it is necessary to build up an SQL
query manually (parameterised of course), beyond what most ORMs
will offer (e.g. a current project involves a fully-temporal database
implementation; I've not had much luck using ORM in such
scenarios - perhaps yours is better the others, I don't know).
OR-mappers (including D-LINQ) aren't the only code that can
write SQL.

Oh, that's true. However reverting to plain SQL is often a maintenance
burden, but if it's unavoidable, it happens of course. Though I'd first
look into Views and after that SQL strings created in code which should
use the o/r core. What exactly do you mean with fully temporal database?

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[Marc Gravell]

What exactly do you mean with fully temporal database?

http://en.wikipedia.org/wiki/Temporal_database

But without the benefit or a temporal query language; regular SQL will
have to suffice...

 

[Frans Bouma [C# MVP]]

http://en.wikipedia.org/wiki/Temporal_database

But without the benefit or a temporal query language; regular SQL will
have to suffice...

That's indeed a problem. There are relational model tricks to work
around this abit, but you always have to do some work indeed.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------