Will I be restricted in how I use linq with LLBLGen in 2.6.

Say for example I have the following:

from m in Customers where m.FirstName.ConsiderateEquals(strSearchFirstName) select m;

where ConsiderateEquals is an extension method that does some loose string matching not possible with SQL (or rather I dont want to).. Even though I presume this will have to pull everything into the CLR, can I do this?

TrickOfTheMind wrote:

Will I be restricted in how I use linq with LLBLGen in 2.6.

Say for example I have the following:

from m in Customers where m.FirstName.ConsiderateEquals(strSearchFirstName) select m;

where ConsiderateEquals is an extension method that does some loose string matching not possible with SQL (or rather I dont want to).. Even though I presume this will have to pull everything into the CLR, can I do this?

We're not done developing the Linq provider so we can't say yet what is and what isn't supported. What I can say now is that Skip() is dropped (we added .TakePage(n, m) instead), as it doesn't match our API, and some other things aren't supported because they're not translatable to SQL (as LLBLGen Pro doesn't support CROSS APPLY neither do a lot of db's). that's not a problem though in 99.999% of the cases.

Now about your question. Linq to LLBLGen Pro focuses on DB queries, so a query written to target the DB should be able to be translatable to SQL. As your query seems to work on objects in memory, you have no problem whatsoever, as it is executed by Linq to Objects in memory.

Linq to LLBLGen Pro looks like: LinqMetaData metaData = new LinqMetaData(adapter); var q = from c in metaData.Customers where c.Country == "USA" select c;

this is translated to LLBLGen Pro objects and is fed to FetchEntityCollection on the adapter passed in. Every element has to be usable in the DB, so if you refer to an extension method you wrote yourself: LinqMetaData metaData = new LinqMetaData(adapter); var q = from c in metaData.Customers where c.Country.SomeExtensionMethod() select c;

it's not likely it will work, as 'SomeExtensionMethod' isn't mappable on a DB element. We're not at the point to support extension methods mapping to DB functions yet, so I can't give you any details how this will look like, however we're thinking of a system where you can supply extensionmethod name - db function name pairs so we can make the mapping. This is flexible, as for example Oracle and DB2 have thousands of functions, as well as MS Access, and we can't possibly add support for them to the API, but with a system like that (it's just string matching anyway) you are able to feed the linq query handler the list you need and it will be able to create proper DbFunctionCall() expressions from it.