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
