couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From muji <freeformsyst...@gmail.com>
Subject Re: Question: COPY /{db}/_local/{docid}
Date Sat, 06 Sep 2014 04:21:18 GMT
Thanks for the insights Jan.

For the purposes of my application it is easy for me to enforce the
`_local` prefix. Incidentally the same applies for COPY with the `_design`
API too.

I guess I brought it up because it is an anomaly in that the COPY verb is
the only API call where special handling of the id is required, all other
`_local` and `_design` API calls transparently handle the document id
prefix.

To clarify I was trying to copy a document within the same database and it
works with the limitation that I need to ensure the id has the `_local`
prefix in order for the local document *not* to be converted to a regular
document.

Regarding the `Location` header response field, it is possible that the
library I am using is doing some unescaping on the `Location` header but I
doubt it, I will check with curl. It does still look incorrect to me and
will not work as is, I am using a database named `mock/database`, but the
slash in the database name is not encoded to `%2F` so a request using the
`Location` header as is will fail with `no_db_file`.

I can do a url.parse() and encode the path part and then use the resulting
value, although right now I have no use for the `Location` header I would
imagine that it would be usable as is.

I am not trying to copy across databases and don't think this is worthy of
a feature request as I can handle it very easily, I just started learning
about the `_local` API and was curious why COPY needed special handling.

Thanks for taking the time to reply!




On 27 August 2014 17:54, Jan Lehnardt <jan@apache.org> wrote:

> Heya,
>
> I implemented COPY and I was definitely not taking _local docs into
> any special consideration, so any behaviour is purely accidental :)
>
> As far as I can tell, COPY just does what it tells you to do: It copies
> a document from one URL to another. It is up to you to ensure that the
> destination URL includes the _local identifier. There isn’t anything
> special to local docs other than the id. So instead of “local” being
> a property of docs, local docs are just docs with an id that has a
> _local/ prefix and docs with this ID are treated specially by CouchDB,
> but they are just regular documents like all other ones and you can
> COPY them to docs with a new id that doesn’t have a _local/ prefix.
>
> The response only includes the new doc id, not the database. The
> proper id for a doc with slashes are the unencoded slashes. Since in
> JSON the slashes don’t need to be encoded, they aren’t encoded in
> the response :) As there is no db info there, a simple replace will
> do the trick.
>
> It isn’t clear from your example, but you might be trying to copy a
> doc across databases. That won’t work, COPY only copies docs within
> a single database. Cross-database COPY could be implemented though,
> if you want to open a feature request.
>
> Hope this helps :)
>
> Best
> Jan
> --
>
>
>
> On 27 Aug 2014, at 08:18 , muji <freeformsystems@gmail.com> wrote:
>
> > Hi all,
> >
> > Just wondering if this is expected behaviour.
> >
> > When using COPY with _local documents and the Destination header
> contains a
> > document identifier that does not start with _local then the document
> > appears to be copied without the copied document identifier starting with
> > _local/, ie, the copied document is no longer local, it is a regular
> > document.
> >
> > If the destination id starts with _local then it is copied as a local
> > document.
> >
> > As the API call is COPY /{db}_local/{docid} I would expect it to only
> copy
> > to another local document.
> >
> > I imagine this is by design but I find it a little counter-intuitive and
> a
> > possible way to end up replicating documents inadvertently.
> >
> > The full request/response log looks like:
> >
> > [COPY] http://localhost:5984/mock%2Fdatabase/_local/mock%2Fdocument
> > {
> >  "destination": "mock/document/copy",
> >  "accept": "application/json",
> >  "host": "localhost:5984"
> > }
> > [201] http://localhost:5984/mock%2Fdatabase/_local/mock%2Fdocument
> > {
> >  "server": "CouchDB/1.6.0 (Erlang OTP/R15B03)",
> >  "location": "http://localhost:5984/mock/database/mock/document/copy",
> >  "etag": "\"9-0c29f3ff80cdf5234680c1f670653388\"",
> >  "date": "Wed, 27 Aug 2014 06:09:50 GMT",
> >  "content-type": "application/json",
> >  "content-length": "81",
> >  "cache-control": "must-revalidate"
> > }
> > {
> >  "ok": true,
> >  "id": "mock/document/copy",
> >  "rev": "9-0c29f3ff80cdf5234680c1f670653388"
> > }
> >
> > Also just looking at the response log again, the Location of the new
> > document has not encoded the {db} {docid} parameters which makes the
> > Location header unusable in this situation.
> >
> > Any help/clarification much appreciated.
> >
> > --
> > mischa (aka muji).
>
>


-- 
mischa (aka muji).

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message