couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: Cloudant Query
Date Sat, 28 Jun 2014 17:17:33 GMT
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 <kxepal@gmail.com> wrote:
> On Sat, Jun 28, 2014 at 3:52 AM, Adam Kocoloski <kocolosk@apache.org> wrote:
>> On Jun 27, 2014, at 6:35 PM, Alexander Shorin <kxepal@gmail.com> wrote:
>>
>>> On Sat, Jun 28, 2014 at 1:55 AM, Adam Kocoloski <kocolosk@apache.org> wrote:
>>>> On Jun 27, 2014, at 5:07 PM, Alexander Shorin <kxepal@gmail.com> 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

Mime
View raw message