Come across an issue when doing a string compare as part of the where section of a linq expression against LINQ for NHibernate.
from x in NhibernateObject
where x.StringCol = "value"
select x
When it runs it retrns a runtime error about casting to an integer. I found a nice post about the issue and the solution at http://jason.pettys.name/archive/2009/09/28/nhibernate-with-linq-error-with-string-comparisons-in-vb.net.aspx
But my question is what is a "visitor" and what code would I write to achive the solution highlighted in the above post - missing the link here !!!
Visitor is a design pattern. You can find a description of it here http://www.dofactory.com/Patterns/PatternVisitor.aspx or here http://en.wikipedia.org/wiki/Visitor_pattern
If I correctly understand the article you linked to (haven't read it fully), then it is required to change NHibernate to work around this problem.
The definition of the visitor pattern is: "Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new
operation without changing the classes of the elements on which it operates."
The namespace of the visitor(s) you want to change is NHibernate.Linq.Visitors. You will probably have more difficulties using VB instead of C# with NHibernate.Linq, because VB3 does not support everything c#3 does. Those problems will be solved if you use .Net 4.0 (or c# of course)
Related
Currently I am using LinqKit / Ms dynamic query example to dynamically build Linq Expressions from strings. This works fine.
LinqKit: http://www.albahari.com/nutshell/linqkit.aspx
Microsoft dynamic Linq queries: http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx
Right now, I am migrating my application from C#3.5 to C#4.0. I am wondering if there is another way (standard way of the framework) to build queries from strings.
I have checked the documentation, but did not find anything yet. Also this is not an issue, since I have the above solution.
Only I'd prefer to use the "standard" features if there some. What's the best practice?
I'm currently doing something like this and I'm very happy with the result. The way I did it was with Entity Framework and the ObjectQuery.Select(string query, ObjectParameters[] params) method. More info here: http://msdn.microsoft.com/en-us/library/bb298787.aspx#Y586.
You won't be making expression from string but using SQL to Entities which does the work very well and was made exactly for that purpose as dynamically making Expression isn't trivial and is actually slower.
Cheers
I have this piece of code:
fee.SingleOrDefault(f => 100.05M >= f.Rate);
In the database the Fee.Rate is a money field stored using invariant culture. But using this select gives an error because my current culture will convert "100.05" to "100,05" wihich results in;
An expression of non-boolean type specified in a context where a condition is expected, near ','.
What is the best way to do this?
This strikes me as less of a LINQ issue and more of a SubSonic issue. Taking a quick peek at their LINQ parser it looks like constant values are handled with ToString() with no regard for culture (see SubSonic.Linq.Structure.TSqlFormatter.VisitConstant). Writing/contributing a patch for this would be ideal (to either allow specification of a culture or at least to use invariant by default), otherwise I think you're stuck switching the thread culture.
Thank you for the answer. As a solution I have modified the SqlServer.ttinclude template to switch to invariant culture in the Find method.
Not a perfect but temporary solution, I'll create a patch or at least report the problem to SubSonic.
I have a scenario where I have custom configured column names, associated operators like < > = between etc. and then a value associated.
I'm trying to determine if it is possible to build up a LINQ query with a dynamic (string) where clause?
I've noticed the Predicate.OR Preditcate.AND stuff, but that is not quite what I'm talking about.
Any suggestions?
If you are talking about a string Where clause (rather than building the expression etc yourself) - then the Dynamic LINQ Library (in the 3.5 samples, IIRC) should suffice.
Note that the example below is for database usage; but you can use it with LINQ-to-Objects by calling .AsQueryable() on your in-memory data.
Actually, there is a specific library from Microsoft (System.Linq.Dynamic) that comes with the C# VS2008 samples that supports this. Get it from here (Microsoft Download)
The library is included in the \LinqSamples\DynamicQuery directory of the samples of above download.
For extensive usage examples check this page: http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx
Also you can use expression trees to created dynamic queries. See:
http://msdn.microsoft.com/en-us/library/bb397951.aspx
http://www.interact-sw.co.uk/iangblog/2005/09/30/expressiontrees
http://blogs.msdn.com/charlie/archive/2008/01/31/expression-tree-basics.aspx
How easy would it be to write a dumb LINQ provider that can just use my class definitions (which don't have any object references as properties) and give me the translated SQL. It can assume the name of the properties and the columns to be same as well as the names of the classes and the underlying tables. Can you please give me some pointers.?
It took me about 4 months of fulltime work (8 hours a day) to build a stable, working provider that implements the entire spec of linq. I would say I had a very simple, buggy and unstable version after about three weeks, so if you're just looking for something rough I would say you're probably looking at anything from a week up to two months depending on how good you are and what types of requiements you have.
I must point you to the Wayward blog for this, Matt has written a really good walkthrough on how to implement a linq provider, and even if you're probably not going to be able to copy and paste, it will help you to get to grips with how to think when working. You can find Matt´s walkthrough here: http://blogs.msdn.com/mattwar/archive/2007/07/30/linq-building-an-iqueryable-provider-part-i.aspx . I recommend you go about it the same way Matt does, and extend the expression tree visitor Matt includes in the second part of his tutorial.
Also, when I began working with this, I had so much help from the expression tree visualizer, it really made parsing a whole lot easier once you could see how linq parsed to queries.
Building a provider is really a lot of fun, even if a bit frustrating at times. I wish you all the best of luck!
Give a look to the LINQExtender project, is a toolkit for creating custom LINQ providers.
Another option for giving you a leg up seems to be re-linq which is a framework for creating custom LINQ providers.
Here's the Source code and a nice overview (pdf) of what's involved in writing one.
I’ve written a tutorial series on my blog base on my experience developing a LINQ-to-SQL provider from scratch, starting with the expression tree composition stage (calling the LINQ methods), continuing with the expression visitor, breaking down of the query into components, parsing the where clause, generating the text and parameter and, eventually, compiling the whole thing into IL using the .NET expression namespace.
I’ve seen many incomplete posts that promised to explain how to write a provider, falling very short of the mark, barely scratching the surface and not actually delivering anything remotely executable.
The blog series I’ve written based on my experience has a sample project available for download with the simple provider that covers only the functionality required by the tutorial example. However, it also includes the production version supporting a number of operations (where, join, first, count, top, etc.), subqueries, nested statements, and etc. Additionally, it produces a cleaner SQL than a lot of what I’ve seen from Entities and LINQ-to-SQL. There’s no unnecessary/redundant nesting, wrapping everything in brackets and etc.
For anyone with a good level of abstract thinking, developing such a provider isn’t such a difficult task many set it out to be. I’ve developed one that’s used in production environment in about 3 months of part time work (meaning some evenings and weekends). From the get go it was aimed with performance and tidy SQL in mind – a goal it achieved.
It was a little hard to find the time to publish this material, but I thought – if it may help someone out there, there’s no reason for this experience to go to waste:
How to write a LINQ to SQL provider in C# Part 1 - Introduction
How to write a LINQ to SQL provider in C# Part 2 - Expression Visitor
How to write a LINQ to SQL provider in C# Part 3 - Where Clause Visitor
How to write a LINQ to SQL provider in C# Part 4 - Compiling Expression Trees
I have created a project 'LinqToAnything' which is designed to make it very very easy to implement a (simple) Linq provider.
I am currently using a CMS which uses an ORM with its own bespoke query language (i.e. with select/where/orderby like statements). I refer to this mini-language as a DSL, but I might have the terminology wrong.
We are writing controls for this CMS, but I would prefer not to couple the controls to the CMS, because we have some doubts about whether we want to continue with this CMS in the longer term.
We can decouple our controls from the CMS fairly easily, by using our own DAL/abstraction layer or what not.
Then I remembered that on most of the CMS controls, they provide a property (which is design-time editable) where users can type in a query to control what gets populated in the data source. Nice feature - the question is how can I abstract this feature?
It then occurred to me that maybe a DSL framework existed out there that could provide me with a simple query language that could be turned into a LINQ expression at runtime. Thus decoupling me from the CMS' query DSL.
Does such a thing exist? Am I wasting my time? (probably the latter)
Thanks
this isn't going to answer your question fully, but there is an extension for LINQ that allows you to specify predicates for LINQ queries as strings called Dynamic LINQ, so if you want to store the conditions in some string-based format, you could probably build your language on top of this. You'd still need to find a way to represent different clauses (where/orderby/etc.) but for the predicates passed as arguments to these, you could use Dynamic LINQ.
Note that Dynamic LINQ allows you to parse the string, but AFAIK doesn't have any way to turn existing Expression tree into that string... so there would be some work needed to do that.
(but I'm not sure if I fully understand the question, so maybe I'm totally of :-))