Community Blogs

In the first part of this series I talked about the fact that Linq to LLBLGen Pro is a full implementation of Linq and why it's so important to use a full linq provider instead of a half-baked one. Today, I'll discuss a couple of native LLBLGen Pro features we've added to our Linq provider via extension methods: hierarchical fetches and exclusion of entity fields in a query. Furthermore some other features will be in the spotlight as well. What I also want to highlight is that using an O/R mapper is more than just filling dumb classes with dumb data: it's entity management , and the O/R mapper framework should offer you tools so you will be able to manage and do whatever you want with the entity graph in memory with as less problems...

Some people asked me what the highlights are of Linq to LLBLGen Pro , which was released this week , as it seems that Linq support is apparently growing on trees these days. In this and some future posts I'll try to sum up some of the characteristic features of Linq to LLBLGen Pro, so you don't have to wade through the 15 articles I wrote about writing Linq to LLBLGen Pro . I'll write several of these articles, this is the first one. I hope to write more of them in the coming weeks. Linq to LLBLGen Pro is a full implementation of Linq The first feature I'd like to highlight is the simple fact that it's a full implementation of a Linq provider. You now might think "Isn't that obvious? It is a Linq provider",...

After almost 11 months of design, development, beta testing and adding final polish, it's here: LLBLGen Pro v2.6 ! This version, which is a free upgrade for all our v2.x customers, has a couple of major new features, the biggest of course being the full implementation of Linq support in our O/R mapper framework. The work on our Linq provider, which we've dubbed 'Linq to LLBLGen Pro', lasted almost 9 months and was discussed on this blog in a series of articles, which I'll linq ( ) to below. In the beginning of writing the Linq provider, I was pretty optimistic that it would be easy and quick, but after a while I got very pessimistic and wanted to skip it entirely as it would simply cost too much effort, and therefore time...

This afternoon I was writing some VB.NET specific Linq queries for the documentation for our upcoming LLBLGen Pro v2.6 (currently in beta) version, and typically I was simply porting over C# queries to VB.NET code and see if they work and if they do, use them, if not, start some cursing, quests for help in the MSDN docs and repeat the process. During my travels through the MSDN Linq documentation and what Microsoft had added to VB9 (.NET 3.5), I ended up in the VB.NET Linq specific language clauses documentation. One of them is about the Aggregate clause. The Aggregate clause was a strange fellow to me. It didn't ring any bell. What does it do? Well, let's look at a typical example: I want to fetch the maximum OrderDate for the Northwind...

Danny Simmons wrote a marketing piece about the project he's been working on for so long: " Why use the Entity Framework? ". I don't expect Danny to be unbiased towards his own work, so at first I just ignored it: Microsoft produces these kind of ' use our stuff, it's better than sliced bread '-articles a dozen times a day. However, this particular article seems to be a discussion subject and is supported by non-Microsoft people on other blogs, so it's time to stop ignoring it and start to refute the contents of the article, despite it being marketing. After all, it doesn't look like it's marketing. I've spend the entire last 6 years of my life on something called Object-Relational Mapping , so I...

Imagine, you're sitting at your desk and you're using the Linq to Sql designer in VS.NET 2008 and you have, say, 50 entities in your model. You're happy about how things are progressing. It took a while to get the model set up, considering the wicked table and field names they cooked up in the DBA dungeon, but after some swearing and too much caffeine, it's done. The model which is smiling back at you is what you had in mind. Rain slams against the window and the DBA you have heard about but never had the chance to meet in person, walks into your office and with her whiskey-shaped voice she almost whispers into your left ear: "Son, I've updated a few tables in your catalog schema, hope you don't mind. See ya!"...

(This is part of an on-going series of articles, started here ) We're getting closer to the goal: a full -featured Linq provider for LLBLGen Pro . Hopefully next week the Linq CTP for LLBLGen Pro is ready for release to customers, fingers crossed! Last time I talked about the function mapping support for database functions and in-memory function/method/property access extravangansa, today I'll discuss one of the cornerstones of using an O/R mapper in the first place: fetching trees of objects using hierarchical fetches. Eager-loading of related data using prefetch paths One of the two ways of fetching hierarchical data is by fetching a tree of entity instances. For example: fetch all customers from Germany and their Order entities and...

(This is part of an on-going series of articles, started here ) Last time I talked about implementing Single. It turned out to be fairly straightforward, but as I explained in the previous episode, it's a weird method and has different behavior related to where it's used in the query: sometimes it does and sometimes it doesn't result in an exception and also it doesn't always result in the same type of exception. This same aspect of not having the same behavior, or better: end result, related to where the element is used in the query is seen with using function mappings, local methods etc. in a Linq query. Let's look at an example or two: // Example A: usage of method mapped onto db function LinqMetaData metaData = new LinqMetaData...

(This is part of an on-going series of articles, started here ) Cast again The last episode in this series contained a remark about Queryable.Cast , and that it can be ignored. I've to correct myself there, this isn't entirely correct. Let's look at the example query at hand: // LLBLGen Pro Linq example var q = from e in metaData.Employee.Where(e => e is BoardMemberEntity).Cast<BoardMemberEntity>() select e.CompanyCarId; Here, the Cast is actually irrelevant because the Where already filters on the BoardMemberEntity type. However in the following small query, it's not: var q = from e in metaData.Employee.Cast<BoardMemberEntity>() select e.CompanyCarId; Here, the Cast is actually a type filter. Well... sort of. The thing is: there...

(This is part of an on-going series of articles, started here ) In the previous post in this series , I mentioned that I had completed the work on all the major parts of a SELECT query. SELECT is what a Linq provider is all about (as Linq queries are focussed on fetching data, not manipulating it). It was sort of a milestone for me, it gave the feeling that most of the work was done. What could possibly be the work in the rest of the Queryable extension methods, compared to nasties like GroupJoin and GroupBy / Aggregates? All / Any So I started with the top of the list of extension methods of the Queryable class and started implementing the ones which weren't implemented / supported yet in the code. The first one, Aggregate , could be skipped...