Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of binary42@gmail.com designates
 209.85.216.52 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=content-type:mime-version:subject:from:in-reply-to:date
         :content-transfer-encoding:message-id:references:to:x-mailer;
        b=it027YeYst2z4uCQgVT6rrWjxIGU0uiKwIxD+Go86/NQfKcxJ/am27pl9xvXbWXhuv
         Tf/aJgieUfUxTpozzSWD1nbwN3GtCIfjhZLqRnWkqQN78M8xEEOXpqQBcNqXLgLPJI1P
         KoawDJWFEhx++E3WEnCf53yUx235Ec6CpizEs=
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Apple Message framework v1237.1)
Subject: Re: JSON Patch Internet Draft 01
From: Brian Mitchell <binary42@gmail.com>
In-Reply-To: <BANLkTi=9jcEtnpXkaYPvCs+NxVvkQE16ng@mail.gmail.com>
Date: Thu, 9 Jun 2011 16:33:02 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <80FD8EDC-6283-4883-901A-9ED52705BACE@gmail.com>
References: <1307642964.1706.84.camel@dynamo>
 <BANLkTimzR4JKJ6Jf7fEdRm2O2ZSVpor4Sw@mail.gmail.com>
 <BANLkTi=9jcEtnpXkaYPvCs+NxVvkQE16ng@mail.gmail.com>
To: user@couchdb.apache.org


On 2011-06-09, at 15:47 , Daniel Itabora=ED wrote:

> This is great stuff!
>=20
> It would be nice to have some more operations like "increment", =
"decrement",
> "push", "pop", "compare-and-swap", etc. I think error handling should =
be
> better addressed, possibly returning an array of "result" objects (or
> something similar).
>=20
> Also, I don=B4t think one should mention idempotency of patches, since =
they
> seem to me inherently state dependent.
>=20
> regards,
> Daniel

This sort of update seems to be better implemented with update handlers. =
Even simple cases like decrement can create lots of cases. What to do at =
0? Do we support decrement other than one? Do we support decrement of =
non-integral values? How about the case where the value isn't a number =
or doesn't exist? All of these cases are easily taken care of by update =
handlers. We can even write an update handler that calls other update =
handlers thanks to code-sharing via common-js modules. Now there is =
debate as to how easy it is to write some of those and if CouchDB should =
make some of it easier but it's a start on the single document level. =
(Also, bulk update calls would be interesting but that's another =
thread.)

Now what I see PATCH being useful for is efficiency. It not only allows =
you to avoid large repetition in payload but could also have slightly =
better concurrency since one could check the current revision against =
the request's revision for just the given patches. One could approximate =
this with an update handler though this might have elegance since it =
could work out of the box if the specification of JSON PATCH is =
carefully crafted and implemented. For now it's just interesting though =
since I think we'll get more milage from update handler improvements. =
Maybe the future will include PATCH support, maybe not.

Brian.=