+972 52-548-6969
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
Markdown turns plain text formatting into fancy HTML formatting.
*italic* **bold**
_italic_ __bold__
Inline:
An [example](http://url.com/ "Title")
Reference-style labels (titles are optional):
An [example][id]. Then, anywhere
else in the doc, define the link:
[id]: http://example.com/ "Title"
Inline (titles are optional):
Reference-style:
![alt text][id]
[id]: /url/to/img.jpg "Title"
Setext-style:
Header 1
========
Header 2
--------
atx-style (closing #'s are optional):
# Header 1 #
## Header 2 ##
###### Header 6
Ordered, without paragraphs:
1. Foo
2. Bar
Unordered, with paragraphs:
* A list item.
With multiple paragraphs.
* Bar
You can nest them:
* Abacus
* answer
* Bubbles
1. bunk
2. bupkis
* BELITTLER
3. burper
* Cunning
> Email-style angle brackets
> are used for blockquotes.
> > And, they can be nested.
> #### Headers in blockquotes
>
> * You can quote a list.
> * Etc.
Three or more dashes or asterisks:
---
* * *
- - - -
End a line with two or more spaces:
Roses are red,
Violets are blue.
Code blocks delimited by 3 or more backticks or tildas:
```
This is a preformatted
code block
```
Set the id of headings with {#<id>} at end of heading line:
## My Heading {#myheading}
Fruit |Color
---------|----------
Apples |Red
Pears |Green
Bananas |YellowTerm 1
: Definition 1
Term 2
: Definition 2Body text with a footnote [^1]
[^1]: Footnote text here
MDD <- will have title
*[MDD]: MarkdownDeep
There are posts all the way to Sep 30, 2016
| Main feed |
|
| Comments feed | |
Comments
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."
RavenLight? Is that available somewhere?
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.
Very interesting article!
By the way, isn't limitation of performing no computation during query too severe?
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.
Hmmm the link doesn't work for me, although it sounds like from the comments I already know what you are going to say ;-)
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.
Rob, It works for me, strange. I sent you the article as PDF by email, at any rate.
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.
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.
Flukus, Linq is a HUGE success story
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)
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)
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.
"least reach" == "least RICH" , sorry for the typo
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.
Comment preview