The Pain of Implementing LINQ Providers previous: Thinking about doing an NHibernate course in Poland next: Review: Microsoft N Layer App Sample, part VII–Data Access Layer is GOOD for you My article in ACM Queue just got published, it discusses implementing Linq providers for NoSQL databases. You can read all about it here: http://queue.acm.org/detail.cfm?id=2001564 Comments 07/08/2011 04:53 PM by Matt Warren Wow nice article, it's a great summary of all the LINQ-related issues that have been discussed on Raven mailing list. I like the summary, "Having a LINQ query available will only hint at things you can do that you actually cannot. It is easier not to have one than to explain why this or that operation is not supported." Also this made me laugh "As mentioned, it actually took more time to build the LINQ provider for RavenDB than it took to build RavenDB itself." 07/08/2011 05:42 PM by jdn RavenLight? Is that available somewhere? 07/08/2011 05:53 PM by Ayende Rahien Jdn, Not yet. No. To be rather more accurate, it is probably code complete, but it isn't product complete. We don't want to put out a project that isn't complete (UI, documentation, the works) and it is on a back burner waiting for more resources. 07/08/2011 06:12 PM by Alexander Very interesting article! By the way, isn't limitation of performing no computation during query too severe? 07/08/2011 07:46 PM by Patrick Smacchia I am a bit divided. While indeed it is a pain to implement a LINQ provider (and I know for a fact) could it be easier to do? I agree with the conclusion, Users love LINQ, after all... and this certainly justifies a lot of pain. Another point is that having a clean LINQ provider puts your product apart from competitors that don't want too much pain. 07/08/2011 08:00 PM by Rob Ashton Hmmm the link doesn't work for me, although it sounds like from the comments I already know what you are going to say ;-) 07/08/2011 10:37 PM by Ayende Rahien Alexander, No, it isn't. Because you can do computation when you are performing the indexing in RavenDB. That allows you to do pretty much whatever you want, and it makes is dead easy to handle a lot of things. It also means that queries are always just index lookups, which are blazingly fast. 07/08/2011 10:39 PM by Ayende Rahien Rob, It works for me, strange. I sent you the article as PDF by email, at any rate. 07/09/2011 12:46 AM by flukus Do people here like using LINQ? I love most of the newer c# features but always thought this was a bit of a miss step, microsoft trying to copy rails too much. 07/09/2011 05:21 AM by Scooletz Speaking about BigTable and its implementation, Cassandra, there is something more, than just a key range. You can chop the result in the additional dimension using SlicePredicate and SliceRange. 07/09/2011 06:29 AM by Ayende Rahien Flukus, Linq is a HUGE success story 07/09/2011 05:10 PM by Rob Ashton Thanks, it was a good read :-) The question is, if you didn't have customers who pay for such a thing, would you do it again? ;-) I still think that the most appropriate solution on a technical level would have been a more direct set of query builders over the top of RavenDB's feature set. (Although not necessarily the most appropriate commercial solution) 07/09/2011 05:10 PM by Rob Ashton Thanks, it was a good read :-) The question is, if you didn't have customers who pay for such a thing, would you do it again? ;-) I still think that the most appropriate solution on a technical level would have been a more direct set of query builders over the top of RavenDB's feature set. (Although not necessarily the most appropriate commercial solution) 07/09/2011 07:51 PM by njy kind of the same opinion here. my tought is that it would've been better if the LINQ story was kind of "layered" from a features availability perspective: a series of interfaces, from the least reach (only operations on a single "type") up up to the most complex interfaces (inheriting from the lowest ones) offering stuff like joins-like operations and whatnot. This way people like you could have implemented only certain aspects of "interrogating a datastore", and there would've been a clear way of saying "i support these operations but not those", using different layered interfaces. 07/09/2011 07:52 PM by njy "least reach" == "least RICH" , sorry for the typo 07/11/2011 08:45 AM by Matt Warren If any one is interested there's a really interesting talk here http://channel9.msdn.com/Events/PDC/PDC10/FT10 where Bart De Smet talks about some of the pain points of implementing a LINQ provider. He offers some solutions but does say that it would be nicer if Microsoft did more of the work of creating a "constrained" LINQ provider. Comments have been closed on this topic.