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! -- ,,,^..^,,,
