I have recently downloaded version 2.6 and am in the very beginning stages of planning a migration for a large project from L2S to LLBLGen. I started reading over the documentation, and a first worry popped into my mind. With the impending release of 3.0, would I be wasting my time doing any coding with the 2.6 version?

In your roadmap you state: "...support for our own runtime framework, Entity framework, Linq to sql and NHibernate, and many more major and minor features." Is the support for Linq to Sql going to change in such a way as to invalidate or legacy-ize any work I may do before that release?

Also, what is the rough timeline on 3.0? I read somewhere January 2010, which has already passed. Is there an updated projection?

Thanks, Jerome

psychlotron wrote:

I have recently downloaded version 2.6 and am in the very beginning stages of planning a migration for a large project from L2S to LLBLGen. I started reading over the documentation, and a first worry popped into my mind. With the impending release of 3.0, would I be wasting my time doing any coding with the 2.6 version?

No not at all In v3.0, the runtime library + templates of our own framework is kept more or less the same, with some changes here and there. We wrote a new designer and mapping system from the ground up, the runtime library and templates and generated code you use in your own application is kept the same more or less.

In your roadmap you state: "...support for our own runtime framework, Entity framework, Linq to sql and NHibernate, and many more major and minor features." Is the support for Linq to Sql going to change in such a way as to invalidate or legacy-ize any work I may do before that release?

Could you elaborate a bit more about what you mean with 'any work I may do' ? v3.0 supports multiple o/r mapper frameworks, so if you use v2.6 and our own framework, you can do so in v3.0, and added to that, you can choose to use other o/r mapper frameworks in v3.0 if you need to, and still use our designer.

Also, what is the rough timeline on 3.0? I read somewhere January 2010, which has already passed. Is there an updated projection? Thanks, Jerome

It's currently in beta for customers. We hope to release the RTM in april 2010

Could you elaborate a bit more about what you mean with 'any work I may do' ? v3.0 supports multiple o/r mapper frameworks, so if you use v2.6 and our own framework, you can do so in v3.0, and added to that, you can choose to use other o/r mapper frameworks in v3.0 if you need to, and still use our designer.

I got the impression from somewhere that there was going to be some sort of support for moving between another O/R like Entity Framework and LLBLGen. Very hazy, sorry for the lack of specificity.

Instead of pursuing that thought, let me approach my concern directly. I have a lot of Linq To Sql (L2S) queries in my application. I am wondering if there is (or will be) some way to change them minimally so as to be compatible with LLBLGen, or will they essentially have to be re-written? If they have to be re-written, then so be it, but I'd rather they didn't

Basically, I was motivated to write the original post because, during my research, I read something that gave me the impression that with v3.0 there would be some new sort of support for Entity Framework and L2S that would help in the process of converting an application from that to LLBLGen. If I read that wrong, I apologize for wasting your time.

However, while I have you on the line, so to speak, I have one other question concerning L2S. I have several complicated, nested queries that I've optimized. I read on your website that "We've spend a lot of time to implement as much Linq functionality as possible...", which I have to admit I find to be a rather vague statement. It makes me wonder just how much Linq functionality is implemented. Will any query I am able to write in L2S work similiarly with LLBLGen? I understand there will probably be some opportunities for further optimization depending on how your pre-fetching works, but I just wonder, in general. For instance, NHibernate's support of L2S, as far as I've read, does not support nested queries.

Thank you, Jerome

psychlotron wrote:

Could you elaborate a bit more about what you mean with 'any work I may do' ? v3.0 supports multiple o/r mapper frameworks, so if you use v2.6 and our own framework, you can do so in v3.0, and added to that, you can choose to use other o/r mapper frameworks in v3.0 if you need to, and still use our designer.

I got the impression from somewhere that there was going to be some sort of support for moving between another O/R like Entity Framework and LLBLGen. Very hazy, sorry for the lack of specificity.

Migrating from one framework to the other is supported at the designer level, as in: you create an EF project for example and after a while you want to move to LLBLGen Pro, just switch the framework, adjust the framework specific settings, regenerate code and you're good to go. Of course, your own code will have to be adjusted manually. Also, not all frameworks support all features, so it's not always easy / seamless, but you can move from one framework to the other. We have planned to add import functionality later on, so you can import existing projects in ef/nh/l2s format as well.

Instead of pursuing that thought, let me approach my concern directly. I have a lot of Linq To Sql (L2S) queries in my application. I am wondering if there is (or will be) some way to change them minimally so as to be compatible with LLBLGen, or will they essentially have to be re-written? If they have to be re-written, then so be it, but I'd rather they didn't

Linq works the same in llblgen pro. There are a couple of things to consider though: - for llblgen pro you have to create a LinqMetaData instance, instead of the context instance - our linq provider doesn't support anonymous types with entity instances, like: from c in metaData.Customer select new { c };, you have to return the entity object yourself. We hope to fix this in v3.0 or a future 3.x version - the L2S loadoptions system is not present in our system, you've to convert that into WithPath() calls, which is straightforward and has more features actually - L2S executes nested queries during enumeration, we execute them during the outer query. This is far more efficient, but has the downside that not all nested queries are possible (only related queries are). - LLBLGen Pro supports paging on all databases, but not skipping rows. So you can page using Skip/Take or our own TakePage() extension method, but you can't skip 3 rows and then take 10 rows, the # of rows you skip has to be a multiply of the page size fetched.

Basically, I was motivated to write the original post because, during my research, I read something that gave me the impression that with v3.0 there would be some new sort of support for Entity Framework and L2S that would help in the process of converting an application from that to LLBLGen. If I read that wrong, I apologize for wasting your time.

When the EF arrived we re-evaluated what direction we should move into with LLBLGen Pro. Clearly we would lose the feature war over the framework eventually to MS or NHibernate, and it's never good to be in a feature war anyway, because when you reach the point of having all necessary features, customers don't care anymore what extra things you have to offer.

So we concluded that besides our framework, our designer was a big asset, so we moved into the designer area with LLBLGen Pro as customers buy a license for the designer/code generator and get our framework for free. V3.0 licenses get you the same thing (designer/code generator and our framework) but now also support for other O/R mapper frameworks (and a lot new features in the designer of course ). The goal is to be the only designer for o/r mappers you'll ever need.

So it's not a goal for us to move everyone away from other frameworks to our own, as that's not realistic: the developer should be able to choose what framework to use, and the designer to use that framework then should be ours (we hope ).

However, while I have you on the line, so to speak, I have one other question concerning L2S. I have several complicated, nested queries that I've optimized. I read on your website that "We've spend a lot of time to implement as much Linq functionality as possible...", which I have to admit I find to be a rather vague statement. It makes me wonder just how much Linq functionality is implemented. Will any query I am able to write in L2S work similiarly with LLBLGen? I understand there will probably be some opportunities for further optimization depending on how your pre-fetching works, but I just wonder, in general. For instance, NHibernate's support of L2S, as far as I've read, does not support nested queries.

Linq to sql is an O/R mapper (simple, but it still is one), it's not a query system. Linq is the query language, so 'nhibernate support of l2s' is something that's not existing: 'nhibernate's support for 'linq', the query language, not the o/r mapper' is what you mean I think.

Linq the query language (the Queryable extension methods) is very complicated to implemented for an O/R mapper as there is not that much documentation, often linq constructs don't map 1:1 onto sql so conversions have to be made (but how?) and the way the expression trees look and have to be consumed is not documented so it's a complex problem to solve. This has lead to many O/R mappers claiming to 'support linq' but very often they implement a small subset of the Queryable extension methods and fail when things get more complex. Thats why we mentioned on the website that we implemented almost all extension methods there were to implement, during a 9-10 month project.

Will every linq to sql query work with llblgen pro's linq provider? no, some edge case queries (a small set, which uses things we didn't implement or do differently, like I explained above) fail. This is the same as when you port a linq to sql query to the EF or port a llblgen pro linq query to linq to sql: some queries will fail, create different SQL or be very inefficient on linq to sql for example. We spend a lot of time to make all linq queries work, and we succeeded for the most part. Like every linq provider we have our dark corners where some things could break, so does linq to sql. These dark corners are actually edge cases and often have workarounds. And we always have our native query system to fall back onto (our linq query system converts to our own query api). Linq is nice, but it's not able to do every query thinkable, our query system can sometimes help out in that area, so you have multiple choices.

Please see these two articles about our linq provider: http://weblogs.asp.net/fbouma/archive/2008/06/17/linq-to-llblgen-pro-feature-highlights-part-1.aspx http://weblogs.asp.net/fbouma/archive/2008/07/03/linq-to-llblgen-pro-feature-highlights-part-2.aspx