Adam Kocoloski wrote:
On Apr 29, 2009, at 12:16 PM, Paul Davis wrote:
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
Ok, but just so we're on the same page, I think Eric was talking about
using the update_seq for that document in the view (i.e., the key for
that document in _all_docs_by_seq), not the server's latest
update_seq. I don't think that usage violates any requirements of the
map function.
Adam
I'd have to think harder on it. I'm pretty sure that you'd end up with
the same documents and different view output depending on the node you
were using. You could almost fix it by transmitting 'dead' update_seq's
but that's a long road for the immediate question.
Paul Davis
