2009 09 03 recent changes in re linq

Published on September 3rd, 2009 at 14:14

Recent changes in re-linq

I’ve checked in a few changes to re-linq regarding the Count property issue that Steve Strong e-mailed me about:

• Properties can now be handled as query operators; from an implementation perspective, their getter methods are registered for parsing, and they get parsed as if the getters had been called directly.
• The Count properties of List<T>, ArrayList, ICollection<T>, and ICollection are now supported and handled exactly the same way as the Enumerable.Count() query method.
• Support has also been added for Array.Length and Array.LongLength, which are also parsed as if they were calls to Enumerable.Count().
• The above means that re-linq will generate trivial sub-queries if a Count property is accessed in a WhereClause or SelectClause. This is done because they are handled just like Count(), which is a query operator – and queries are always wrapped into QueryModels. You can detect such trivial sub-queries by using the new QueryModel.IsIdentityQuery() method.
• The ToString() representation of QueryModel has also been simplified for identity queries.

In addition, I've fixed a bug in StreamedSingleValueInfo and removed the ResultType property of AverageResultOperator. The result types of result operators and QueryModels should always be determined via GetOutputDataInfo() because they might change as a QueryModel is transformed.

That’s it for now. I’ll be on holiday for the next two weeks, so if you want to contact me, be patient :)

- Fabian

Comments

Carlos Cubas - September 21st, 2009 at 14:19

Fabian,

I asked Steve Strong in his blog about this, but I figure I’d ask here as well. Is re-linq currently able to handle VB.Net. expression trees? It is my understanding that VB.Net generates expression trees that are different from the c# ones.

Fabian Schmied - September 21st, 2009 at 14:32

Carlos,

we haven’t yet been able to translate our re-linq integration test suite to VB.NET, but I’m sure we’ll find the time do so at some point.

In principle, re-linq was written to not depend on any implementation-specific expression tree patterns. This means that you can hand-construct your expression tree; re-linq should still be able to interpret it.

So, even though it’s possible that we’ve missed a query method overload used only by the VB.NET compiler, the overall re-linq architecture does not depend on any compiler specifics.

Full compatibility can only be guaranteed once we’ve ported our test suite; but I’m convinved there shouldn’t be any major stumbling blocks.

Michael Ketting - September 22nd, 2009 at 12:00

Our mailing list has additional info about adding integration tests for re-linq (http://groups.google.com/group/re-motion-dev/msg/fb5050d36070649d)

Michael