Monday, March 9, 2009
1. Old, good LINQ to LDAP by Bart De Smet
2. Surprisingly complete tutorial by Matt Warren where a LINQ-to-SQL-like custom provider is explained very thoroughly.
Do not also miss the LINQ's Dynamic Query helper and the MetaLINQ to discover other interesting variations on LINQ.
Friday, March 6, 2009
In general, XPO is great. I like it because of two features:
- the ability to automatically update the database schema when connecting from the new version of the object model
- the default "mark-as-deleted" way of removing objects
There's however one scar on its beautiful face - incomplete Linq support.
No matter how fancy the Linq-To-Whatever implementation is - without Skip and Take it can never be fully adopted in enterprise systems. And XPO's implementation of Linq lacks the support of the Skip operation.
I am afraid that this is because XPO's implementation of paging is flawed by design: if you forget about Linq for a second, the only way to paginate is to use the XPPageSelector over your collection.
If you run the above code and in the same time you trace queries which are executed, you'll learn that:
- first, the whole collection of objects' identifiers is retrieved from the data source
- the page selector selects the identifier subset which refers to the page you select
- then, another query retrieves all the columns but only from the selected page of items
And if you realize that there are in fact two queries required to retrieve selected page of data, then you imagine how ineffective (difficult?) this could be when implementing Linq's Skip this way!
It's then no surprise that the only answer to the "when the Skip operator will be supported?" is "sorry, Skip is not supported":
Edit: if you find this post in early 2010 or later please consider it outdated. Both skip and take are now correcly handled by XPO's Linq provider. I've blogged about it.
Using LinqToSQL is fun and speeds up a lot of things. However, there are issues with LinqToSQL which confuse people. Ultimately, some of these people tend to think that LinqToSQL is useless because things that should be obvious are not such obvious. Over a year ago I wrote a short blog entry on one of such basic issues.
Another such "not-so-obvious" thing is the issue of "ordering". One of the common requirements is to be able to order by the name of the property and not by the property itself. For example, if you use ObjectDataSource, then you know that the sorting parameter is passed to the object responsible for data retrieving by name of the parameter.
Let's take a look at two LinqToSQL ordering attempts:
In the example code above, the first linq clause is obvious - the ordering uses the property "Property" in a direct way. However, in in the second clause we use the name of the property.
You are to answer two following questions:
1. Why the second clause does not produce correct results, although it compiles correctly?
2. How is it possible then to build generic linq expressions which sort objects by names of their properties.
By generic I mean that following solution is not acceptable: