Linq

ADO.Net Data Services with NHibernate

Ayende Rahien — Mon, 21 Jul 2008 11:23:03 GMT

Shawn Wildermuth has bridged the gap between the two, implementing IUpdatable on top of Linq to NHibernate. This means that you can now expose your NHibernate domain model as a set of REST services.

This functionality is now included with Linq for NHibernate. Thanks Shawn!

There is a live sample here: http://www.silverlightdata.com/Simple/NHibernate.aspx

Or you can hit the URLs directly and see what kind of formatting it has:

From a technological perspective, I think this is awesome. However, there are architectural issues with exposing your model in such a fashion. Specifically, with regards to availability and scalability on the operations side, and schema versioning and adaptability on the development side.

ADO.Net Data Services are a very thin wrapper around a DB, and as such, they should be treated as such. Do not expose them where you wouldn't want to expose your DB as well.

Linq for NHibernate Adventures

Ayende Rahien — Sat, 16 Feb 2008 20:16:23 GMT

So for the last few hours I have been getting back into the Linq for NHibernate project, after having left it for far too long. I am beginning to think that building a Linq provider might not have been the best way to learn C# 3.0, but never mind that now.

It is with great pride that I can tell you that the following query now works:

from e in db.Employees
select new { Name = e.FirstName + " " + e.LastName, Phone = e.HomePhone }

Why is this trivial query important? Well, it is important because about a year ago I said that there is only a single feature in Linq for SQL that NHibernate doesn't have. I also promised to fix it the moment that someone would tell me what it is. No one did, so it waited until today.

The main issue had to do with the Criteria API and handling parameters, no one ever needed to do that, it seems. When they did, they generally used HQL, which did have this feature. Since I have based Linq for NHibernate on the Criteria API*, that was a problem.

Now that ReSharper works on C# 3.0, I can actually get things done there, so I sat down and implemented it. It is surprisingly difficult issue, but I threw enough code on it until it gave up (I wonder if there is a name for nested visitors... ).

At any rate, I strongly recommend that you'll take a look at the project. And bug (fixes) and other patches are welcome**.

* This decision was important for two reasons, the first was that it is generally easier to use the Criteria API programmatically, and the second was that I wanted to ensure that the Crtieria API (which I favor) was a full featured as the HQL route.

** Yes, I know that I'll regret it.

The cost of inappropriate linqing

Ayende Rahien — Tue, 04 Dec 2007 19:14:31 GMT

I read this post with interest, apparently Linq for SQL is doing something odd, because I can't quite believe the results that this guy is getting. From the post:

So I dug into the call graph a bit and found out the code causing by far the most damage was the creation of the LINQ query object for every call! The actual round trip to the database paled in comparison

I can't imagine what they are doing there to cause this performance characteristics.

From my own experiments with Linq, it should definitely not produce this amount of efforts.

Awkward Testability for Linq for SQL

Ayende Rahien — Thu, 16 Aug 2007 04:54:57 GMT

Note: I am writing this post in the express hope that it would help to change the current situation.

I have been just recently informed about a significant problem with Linq for SQL. It doesn't support testing easily. You can see the bug report here, and as usual, it was closed as Won't Fix without even providing an explanation. Did I mention already that I don't like Connect's approach to it? Yes, I did.

The root problem is a fairly simple one. Linq for SQL relies on reams of generated code, which means that if I have code line this:

var customers = from c in context.Customers 
  select c;

Then I have no really easy way to mock what is going on in here. The generated code provides a concrete class without an interface, so it is very hard to mock, and naturally, System.Data.Linq.Table<T> is sealed, has internal stuff, and is utterly hostile to mocking.

You have to use mocking if you want to use the code above without hitting the database, and this is a core part of the way a lot of people work. Linq for SQL doesn't take that into account.

The requirement for mocking aren't really that onerous, we need and interface generated for the context class, and interface for Table<T> and that the generated code will default to using interfaces by default (Best Practices, anyone?).

Having to write adapters classes is something that TDDers on the .Net platform has become very familiar with, because of the insistence of using untestable practices throughout the framework. I am fairly tired of that, and I would certainly like to be able to skip this tiring process for once.

It is shocking to me that in this day and age the Linq for SQL team can still believe utterly ignore such practices and put hurdles in the path of easy testability.

Are we back to demos vs. reality development?

To finish, this bug has been closed, so it is not possible even to vote for it. At the very least, I would like to hear an explanation, and it had better not involved "lack of resources".

Dreaming in Code: Multi Linq

Ayende Rahien — Sun, 24 Jun 2007 06:04:15 GMT

I was asked how we will approach the same Multi Query approach with Linq integration, here are some thoughts about it.

var posts = from post in data.Posts
            where post.User.Name == "Ayende"
		orderby post.PublishedDate desc;
var postsCount = posts.Count();
posts.Skip(10).Take(15);

new LinqQueryBatch()
 .Add(posts)
 .Add(postsCount)
 .Execute();//perform the query

foreach(Post p in posts)//no query
{
  Console.WriteLine(p.ToString());
}
//no query
Console.WriteLine("Overall posts by Ayende: {0}", postsCount.Single() );

The LinqQueryBatch in this case doesn't need to pass delegates to process the results, it can modify the Linq Query directly, so trying to find the result will find the one that was already loaded when we executed the multi query.

Again, this is something that I am merely thinking about, no concrete code created.

LINQ to SQL - Dynamically Constructing Queries - Um... No!

Ayende Rahien — Tue, 24 Apr 2007 09:48:27 GMT

Mike Taulty is talking about constructing queries dynamically in Linq to SQL. Sorry, but my response to that is Yuck! Here is the code that he shows:

  NorthwindDataContext ctx = new NorthwindDataContext("server=.;database=northwind");
    
       var query = from c in ctx.Customers
                   where c.Country == "Germany"     
                   select c;
    
       if (RuntimeCriterionOneApplies()) 
       {
        query = from c in query
                where c.City == "Berlin"     
                select c;
       }
    
       if (RuntimeCriterionTwoApplies())
       {
        query = from c in query
                where c.Orders.Sum(o => o.Freight) > 100
                select c;
       }
    
       foreach (Customer c in query)
       {
        Console.WriteLine(c.CustomerID);
       }

~~This is not constructing queries dynamically, it is choosing a query dynamically. This isn't what I talk about when I am talking about constructing a query dynamically. You can look~~ ~~here~~ ~~as what I consider a complex query that is being constructed dynamically.~~

~~Mike, how would you handle that scenario in Linq?~~

Update: I really should pay more attention when I am reading the code. Sorry Mike, the code that you have will work for the scenario that I have. I don't think that the syntax is very elegant for this scenario, but it will work. I missed the "from q in query" and read is as if a new query were constructed in each if.

Linq for NHibernate: Functions

Ayende Rahien — Fri, 13 Apr 2007 23:19:20 GMT

Bobby Diaz is still producing some amazing stuff. The new addition is native support for SQL functions. Take a look at this code:

DateTime date = new DateTime(1960, 1, 1);

var query = ( from e in db.Employees
                   where db.Methods.Year(e.BirthDate) >= date.Year && db.Methods.Len(e.FirstName) > 4
                   select e.FirstName )
                   .Aggregate(new StringBuilder(), (sb, name) => sb.Length > 0 ? sb.Append(", ").Append(name) : sb.Append(name));

Console.WriteLine("Birthdays after {0}:", date.ToString("yyyy"));
Console.WriteLine(query);

Check out Bobby's post for the full details. I am going to write a full overview of the current state of Linq for NHibernate soon. The situation so far is looking very nice.

Linq For NHibernate: More Implementation Details

Ayende Rahien — Thu, 05 Apr 2007 02:05:47 GMT

Bobby Diaz did some more work recently, and has documented it here. Interesting reading...

Linq for NHibernate Updates: Adding a new committer

Ayende Rahien — Tue, 27 Mar 2007 18:32:49 GMT

Following several good patches, I have added Bobby Diaz to the Rhino Tools project, which currently includes the Linq for NHibernate implementation as well. I expect that the new stuff will be up in the repository shortly.

Just to remind you, I am still looking for more volunteers to help with the implementation, so if you are into futuristic technologies, just dive right into the code and the implementation details. And be sure to send me (or Bobby) a patch or two.

Linq For NHibernate: Orderring and Paging

Ayende Rahien — Tue, 20 Mar 2007 07:55:02 GMT

Bobby Diaz has implemented orderring and paging support for Linq to NHibernate, so this works:

(from c in nwnd.Customers select c.CustomerID)
.Skip(10).Take(10).ToList();

As well as this:

var query = from c in nwnd.Customers
   where c.Country == "Belgium"
   orderby c.Country descending, c.City descending
   select c.City;

Thanks again, Bobby, and the new code is on SVN.