Ayende @ Rahien

Refunds available at head office

The Pain of Implementing LINQ Providers

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

Matt Warren
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."

jdn
07/08/2011 05:42 PM by
jdn

RavenLight? Is that available somewhere?

Ayende Rahien
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.

Alexander
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?

Patrick Smacchia
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.

Rob Ashton
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 ;-)

Ayende Rahien
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.

Ayende Rahien
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.

flukus
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.

Scooletz
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.

Ayende Rahien
07/09/2011 06:29 AM by
Ayende Rahien

Flukus, Linq is a HUGE success story

Rob Ashton
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)

Rob Ashton
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)

njy
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.

njy
07/09/2011 07:52 PM by
njy

"least reach" == "least RICH" , sorry for the typo

Matt Warren
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.