couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: Atomicity of getting update_seq after reading data
Date Thu, 31 Dec 2009 04:13:14 GMT
On Wed, Dec 30, 2009 at 4:15 AM, Robert Dionne
<dionne@dionne-associates.com> wrote:
> It's in the db record in src/couchdb/couch_db.hrl, #db.update_seq, so you'll want to
look around for a Db variable and pull it out of there, I think. I haven't absorbed the view
stuff completely yet.
>

This is basically correct, but in order to find the seq for the view
you need to look for

#group.current_seq

If you get fed up with the Erlang, don't hesitate to holler, and we
can help. Often there are a lot of people in #couchdb on
irc.freenode.net who can help you in real-time too.

The #group.current_seq won't be effected by full/delayed commit. Also
it will accurately reflect status even with stale=ok

Chris

> There's also this delayed commit thing that might affect it, .i.e. the value you grab
may not be yet committed to disk which would possibly affect subsequent calls to the _changes
api. Someone should comment on whether this is just my needless worrying or not.
>
> cheers,
>
> Bob
>
>
> On Dec 30, 2009, at 5:12 AM, Joscha Feth wrote:
>
>> Hi Relaxers,
>>
>> there was a discussion in user@ about a common problem when reading
>> from couchDB and wanting to also informed of any changes on the data
>> after having read it.
>>
>> Current standard procedure to do this is:
>>
>> 1)  Get the update_seq from the database
>> 2)  Get data from a view
>> 3)  Connect to _changes since updae_seq from #1
>>
>> As making two requests are not atomic, there might have been updates
>> between 1) and 2) which need to be handled afterwards (data could even
>> have been removed completely in between).
>>
>> Now there was a suggestion to add an X-Update-Seq header to any view
>> coming back which allows to not only save an additional request, but
>> also make this thing atomic.
>> Chris Anderson proposed to not add a header, but extend the JSON:
>>
>> {"total_rows":1000,"offset":0, "update_seq": 1001, "rows":[
>> {"id":"1","key":1,"value":null},
>> ...
>>
>> which I think is an equivalent solution.
>>
>> I would be willing to write a patch for this, but I am a total beginner
>> in Erlang. I searched the code a little and found that one change
>> should be made in "couch_httpd_view.erl":
>>
>> json_view_start_resp(Req, Etag, TotalViewCount, Offset, _Acc) ->
>>       UpdateSeq = get_update_seq_from_somewhere(),
>>   {ok, Resp} = start_json_response(Req, 200, [{"Etag", Etag}]),
>>   BeginBody =
>> io_lib:format("{\"total_rows\":~w,\"offset\":~w,\"update_seq\":~w,\"rows
>> \":[\r\n",
>>           [TotalViewCount, Offset, UpdateSeq]),
>>   {ok, Resp, BeginBody}.
>>
>>
>> and get_update_seq_from_somewhere() is still a mistery for me :-)
>> Can anyone give me a hint where/how to get the latest update_seq
>> cleanly?
>>
>> regards,
>> Joscha
>>
>> --
>>
>>
>
>



-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Mime
View raw message