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 <[email protected]> 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 <[email protected]> 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).
