couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: couch sequence numbers and _all_docs_by_seq
Date Wed, 29 Apr 2009 16:16:19 GMT
Adam Kocoloski wrote:
> On Apr 29, 2009, at 4:08 AM, eric casteleijn wrote:
>
>> Paul Davis wrote:
>>> Eric,
>>> Implementation isn't a problem, but I would fear that replication
>>> could screw views up. As in, your views would depend on the order of
>>> document modification which could be impacted quite heavily by
>>> replication etc.
>>
>> Ah right, hadn't thought of that. So in a system using replication, 
>> views that would use the sequence number as a key would get a severe 
>> performance penalty? (Just checking to see if I understand the 
>> implications.) That might be a good enough reason not to expose this 
>> as a feature, lest people start depending on it and saying CouchDb is 
>> slow as a result.
>>
>> If this is true, I suppose it also holds for the built in 
>> _all_docs_by_seq view?
>
> I'm not sure Paul's comment is performance-related, actually. I think 
> he was more concerned that a view which incorporates update_seq could 
> give different results on two servers that are using replication to 
> stay synchronized with one another. Paul, correct me if I'm 
> misinterpreting you.
>
Yep that's the issue. If you use the update sequence in your map view 
then it violates those math words about same input means same output. 
Because the update_sequence will change for every PUT etc, and 
replication could give it an entirely different update_seq.

A thought, you could look at _all_docs_by_seq and then use multi-get 
against your view.

HTH,
Paul Davis
> At the moment the replicator doesn't try to update documents on the 
> target in the exact same order that they were updated on the source, 
> but I think it could be done without too much of a penalty if we 
> decided it was necessary. Regards,
>
> Adam


Mime
View raw message