I'm fully supportive of the MongoDB-like query syntax. It's the difference between de facto standards and de jure, and in this case, I absolutely think this is the right choice.
I wrote a bit more about this from a cloud perspective, with the standardisations efforts around the AWS API. This stuff is hard work, however you do it. https://blog.engineyard.com/2014/open-cloud-interface Only other thing I have to add to this thread is that as the code is being developed as a Cloudant feature first and foremost, we'll have to do IP clearance to bring it to CouchDB. Not a big issue, but something to keep in mind. On 28 June 2014 02:12, Alexander Shorin <[email protected]> wrote: > On Sat, Jun 28, 2014 at 3:52 AM, Adam Kocoloski <[email protected]> wrote: >> On Jun 27, 2014, at 6:35 PM, Alexander Shorin <[email protected]> wrote: >> >>> On Sat, Jun 28, 2014 at 1:55 AM, Adam Kocoloski <[email protected]> wrote: >>>> On Jun 27, 2014, at 5:07 PM, Alexander Shorin <[email protected]> wrote: >>>> >>>>> Hi Adam and thanks for the answers. Few more questions about if you don't >>>>> mind: >>>>> >>>>> 1. Since "The _index endpoint is mostly syntactic sugar and validation >>>>> on top of _design documents." doesn't this violates REST API >>>>> principles when each object must have since operational endpoint? Why >>>>> the _index/_find doesn't follow common pattern as: >>>>> /db/_design/ddoc/_index/foobarbaz ? >>>> >>>> There may well be improvements to the _index API that would allow it to >>>> better conform to REST principles. >>>> >>>> I'm not sure the same applies for _find. A significant part of the power >>>> of the _find operator is its ability to select from among various indexes >>>> on the DB in order to respond to a declarative query. Scoping _find to a >>>> design document doesn't make sense. One might argue about GET vs. POST in >>>> the API but we've seen time and again that taking a complex query and >>>> URL-encoding it makes for an unfriendly experience. We started that way >>>> with our Search offering and ultimately exposed a POST variant. Did you >>>> have something else in mind regarding REST and _find? >>> >>> No, that's probably my lack of knowledge about how they works. I >>> thought that _find and another sugar on top of index querying, but I >>> feel now it's completely different thing. >>> >>>>> 2. What were the reasons for taking MongoDB approach? I could see the >>>>> one about share users market, but only. >>>> >>>> You write about user market share like it's a bad thing :) Seriously >>>> though, there are certainly alternatives out there for writing declarative >>>> queries against JSON datastores, but we didn't feel strongly enough about >>>> the superiority of any of them to ignore all the developers who have >>>> recognized that MongoDB's query documents offer a pleasant and powerful >>>> way to interact with JSON(-ish) data. >>> >>> Didn't wrote about user market as about something bad, but I'm glad >>> that you asked about bad things (: There is a doubt for the case when >>> users will expect _exactly_ the same behavior (even bugged) from >>> Cloudant Query implementation as MongoDB does. This remind the SQL >>> history, when major database players took the same specification, but >>> during marketing war started develop their own deviations and now we >>> have what we have - a lot of partially compatible deviations of the >>> same specification. Won't the history repeat itself for Cloudant Query >>> since the goal to share user market by sharing foreign solutions makes >>> Cloudant heavily depended from MongoDB company policy about plans for >>> their query syntax? You have to always play catch-up in cases of >>> bringing significant improvements or making breaking compatible >>> decisions. >>> >>> That's why I had asked about alternative solutions, especially if they >>> are proposed or aims to be a common standard. >> >> So there's a few things going on here. If we had gone out and implemented >> the MongoDB wire protocol and said "hey everybody, bring your MongoDB apps >> and run them on Cloudant!" then we'd absolutely run into a situation where >> any deviations we had from the MongoDB implementation would be magnified, >> and we'd be perpetually working to stay in sync with our friends down in New >> York. But that's not what we've done here. We're still sporting an HTTP+JSON >> interface. The query language should look familiar to anyone who's developed >> against MongoDB, but byte-for-byte fidelity is not the goal. >> >> Standardization is a complex topic. I kind of feel like you're arguing both >> ways in in that you're expressing a preference for query languages that aim >> to be a common standard, but then worrying about history repeating itself >> vis a vis SQL (which, last I checked, *is* a common standard). If your >> proposed standard takes off then you'll always run the risk of vendors >> releasing proprietary extensions to said standard. That said, I happen to >> believe that the standardization of SQL catalyzed a wave of adoption of >> RDBMS and was a great thing for the industry as a whole. It may be that >> we'll see a similar thing occur in document databases -- who knows? Cheers, >> >> Adam > > Actually, I wasn't argue for any way: each has own benefits and flaws. > I was mostly curious about why other alternatives were rejected, but I > see your points and they are clarifies Cloudant Query design and > goals. Wish you receive positive feedback and write success story > about (: > > Thanks a lot for your answers! > > -- > ,,,^..^,,, -- Noah Slater https://twitter.com/nslater
