What's the output of these two commands? curl http://10.100.169.99:5984/api_keys/test-key?conflicts=true curl http://10.100.169.99:5984/api_keys/test-key?open_revs=all
On Tue, Jul 3, 2012 at 11:20 PM, Matt Cheers <[email protected]> wrote: > Paul, > > Thanks for your quick response. > There is delete logic which i've included as well. The first PUT returns > [rev:1] seems strange (to me). Couch version is 1.2 (linux). > > Regards, Matt > > --------------------------------------------------- > > Deleting key: test-key > > GET 'http://10.100.169.99:5984/api_keys/test-key > > Getting Key: test-key Response: 200 > Getting Key: test-key Data: [_rev:27-cdbc4ed3efd08dc07f9834eba370baba, > application:search, _id:test-key] > > DELETE > 'http://10.100.169.99:5984/api_keys/test-key?rev=27-cdbc4ed3efd08dc07f9834eba370baba&;' > Deleting Key: test-key Response: 200 > Deleting Key: test-key Data: [ok:true, id:test-key, > rev:28-50a1da020ff32600df07c332efd805e2] > > Loading key: test-key > > GET 'http://10.100.169.99:5984/api_keys/test-key > > Getting Key: test-key Response: 404 > Getting Key: test-key Data: null > > PUT 'http://10.100.169.99:5984/api_keys/test-key > > Updating Key: test-key Response: 201 > Updating Key: test-key Data: [ok:true, id:test-key, > rev:1-3ee0651cf72c96950f2c8809ae2675eb] > > GET 'http://10.100.169.99:5984/api_keys/test-key > > Getting Key: test-key Response: 404 > Getting Key: test-key Data: null > > PUT 'http://10.100.169.99:5984/api_keys/test-key > > Updating Key: test-key Response: 201 > Updating Key: test-key Data: [ok:true, id:test-key, > rev:29-f8ff63465214118dc98599a96b7cc38b] > > GET 'http://10.100.169.99:5984/api_keys/test-key > > Getting Key: test-key Response: 200 > Getting Key: test-key Data: [_rev:29-f8ff63465214118dc98599a96b7cc38b, > application:search, _id:test-key] > > Taken 2 attempts to create. > > > On 04/07/12 10:03, Paul Davis wrote: >> >> Can you run that command with a GET before your first PUT as well as >> showing all of the JSON bodies sent and received? >> >> My first guess is you're not handling conflicts correctly. >> >> On Tue, Jul 3, 2012 at 7:50 PM, Matt Cheers<[email protected]> >> wrote: >>> >>> Hi, >>> >>> I have a question on behaviour I'm seeing POSTing docs to the database >>> but >>> then not always being able to immediately GET them. Generally it takes 2 >>> attempts for a successful fetch. I had assumed a POST is synchronous and >>> document would then be immediately available. >>> >>> Not sure if it makes a difference, delayed_commits is set to false >>> currently. Though I've tried both settings. I've looked at couch's >>> durability matrix page and also assumed that is outside the scope of >>> this. >>> >>> Thanks, Matt >>> >>> Example output: >>> Loading key: test-key >>> >>> PUT 'http://couch:5984/keys/test-key >>> Updating Key: test-key Response: 201 >>> >>> GET 'http://couch:5984/keys/test-key >>> Getting Key: test-key Response: 404 >>> >>> PUT 'http://couch:5984/keys/test-key >>> Updating Key: test-key Response: 201 >>> >>> GET 'http://couch:5984/keys/test-key >>> Getting Key: test-key Response: 200 >>> Taken 2 attempts to create. >>> >>> >>> { >>> println "Loading key: ${key}" >>> put(key, json) >>> >>> def attempts = 1 >>> while (!get(key)) { >>> attempts++ >>> Thread.sleep(100); >>> put(key, json) >>> } >>> println "Taken ${attempts} attempts to create." >>> } >>> >>> def put(String key, json) { >>> def params = [path: "/keys/${key}", body: json] >>> def response = client.put(params) >>> println "Updating Key: ${key} Response: ${response.status}" >>> } >>> >>> def get(String key) { >>> def params = [path: "/keys/${key}"] >>> def response = client.get(params).data >>> println "Getting API Key: ${apiKey} Response: ${response.status}" >>> return response.data >>> } >>> >>> ________________________________ >>> This email (including any attachments) is confidential and may be >>> privileged. If you have received it in error, please notify the sender by >>> return email and delete this message from your system. Any unauthorised >>> use >>> or dissemination of this message in whole or in part is strictly >>> prohibited. >>> Please note that emails are susceptible to change and we will not be >>> liable >>> for the improper or incomplete transmission of the information contained >>> in >>> this communication nor for any delay in its receipt or damage to your >>> system. We do not guarantee that the integrity of this communication has >>> been maintained nor that this communication is free of viruses, >>> interceptions or interference. > > > > This email (including any attachments) is confidential and may be > privileged. If you have received it in error, please notify the sender by > return email and delete this message from your system. Any unauthorised use > or dissemination of this message in whole or in part is strictly prohibited. > Please note that emails are susceptible to change and we will not be liable > for the improper or incomplete transmission of the information contained in > this communication nor for any delay in its receipt or damage to your > system. We do not guarantee that the integrity of this communication has > been maintained nor that this communication is free of viruses, > interceptions or interference.
