On Mon, Jan 25, 2010 at 7:24 AM, Joscha Feth jos...@feth.com wrote:
Robert Newson wrote:
It's not clear if any of that belongs inside couchdb but clearly
something like it would be useful to a lot of folks. Perhaps it's
another tool outside of couchdb that, like couchapp, adds some finesse
Absolutely! I'm voting on this one. That would ease my work immensely.
On Sun, Jan 24, 2010 at 12:20 PM, Brian Candler b.cand...@pobox.com wrote:
Have there been any more thoughts about being able to use _rev as a history
mechanism?
I think this just means that certain older _revs can survive
Brian Candler wrote:
Have there been any more thoughts about being able to use _rev as a
history mechanism?
+1 from here - this would make the revision scenario for my current
project incredibly easy!
regards,
Joscha
--
I gave this some more thought over the weekend and don't think it's a good
idea. Admittedly I'm not as deep in the code as the core devs but this strikes
me as non-trivial to get right. There has also been a lot of effort put into
telling folks to not think of _rev as a history mechanism. It
fwiw, I have the same hinky feeling about this proposal. If
implemented, it would be the case that revisions are a history
mechanism under user control, when couch has always, and rightly, said
that it is not.
when you PUT a new document over an existing one you are implicitly
removing the
On Mon, Jan 25, 2010 at 9:38 AM, Robert Newson robert.new...@gmail.com wrote:
fwiw, I have the same hinky feeling about this proposal. If
implemented, it would be the case that revisions are a history
mechanism under user control, when couch has always, and rightly, said
that it is not.
when
Robert Newson wrote:
It's not clear if any of that belongs inside couchdb but clearly
something like it would be useful to a lot of folks. Perhaps it's
another tool outside of couchdb that, like couchapp, adds some finesse
over a fundamental concept?
But isn't there the chance that any
On Mon, Jan 25, 2010 at 02:38:22PM +, Robert Newson wrote:
when you PUT a new document over an existing one you are implicitly
removing the document that was previously there. A concurrent read
operation might see the b+tree before or after that change; either
answer is consistent with
Have there been any more thoughts about being able to use _rev as a history
mechanism?
I think this just means that certain older _revs can survive compaction, and
ISTM that the simplest way to achieve this would be to have a bit which
marks a particular revision as pinned (cannot be discareded).
