On Feb 3, 2010, at 4:53 AM, Brian Candler wrote:
On Tue, Feb 02, 2010 at 09:41:28PM +, Robert Newson wrote:
If couchdb tracked replication by a Merkle tree, it would obsolete the
update_seq mechanism?
Only if you weren't doing filtered/selective replication. And probably only
if there
On Thu, Feb 4, 2010 at 10:19 AM, Adam Kocoloski kocol...@apache.org wrote:
On Feb 3, 2010, at 4:53 AM, Brian Candler wrote:
On Tue, Feb 02, 2010 at 09:41:28PM +, Robert Newson wrote:
If couchdb tracked replication by a Merkle tree, it would obsolete the
update_seq mechanism?
Only if you
On Feb 4, 2010, at 10:44 AM, Paul Davis wrote:
On Thu, Feb 4, 2010 at 10:19 AM, Adam Kocoloski kocol...@apache.org wrote:
On Feb 3, 2010, at 4:53 AM, Brian Candler wrote:
On Tue, Feb 02, 2010 at 09:41:28PM +, Robert Newson wrote:
If couchdb tracked replication by a Merkle tree, it would
On Thu, Feb 4, 2010 at 08:17, Adam Kocoloski kocol...@apache.org wrote:
If we went ahead and implemented this I think the UUID becomes superfluous
from the replicator's perspective. You wouldn't want to restrict this Merkle
tree check to UUID-matched DBs, as it would be useful for reducing
On Feb 4, 2010, at 5:05 PM, Randall Leeds wrote:
On Thu, Feb 4, 2010 at 08:17, Adam Kocoloski kocol...@apache.org wrote:
If we went ahead and implemented this I think the UUID becomes superfluous
from the replicator's perspective. You wouldn't want to restrict this
Merkle tree check to
On Tue, Feb 02, 2010 at 09:41:28PM +, Robert Newson wrote:
If couchdb tracked replication by a Merkle tree, it would obsolete the
update_seq mechanism?
Only if you weren't doing filtered/selective replication. And probably only
if there was nothing else different between the two databases
I'm not entirely happy with this patch and I'd like some help figuring
out what to do about it.
I foresee problems when database files are copied or backed up on
disk. It's possible to end up with two couchdb instances hosting
databases with the same uuid. The problem is that the uuid is no
My mind immediately turns to git histories... but do we want to go there?
On Tue, Feb 2, 2010 at 11:25 AM, Randall Leeds randall.le...@gmail.com wrote:
I'm not entirely happy with this patch and I'd like some help figuring
out what to do about it.
I foresee problems when database files are copied or backed up on
disk. It's possible to end up with two couchdb
On Tue, Feb 2, 2010 at 11:39, Chris Anderson jch...@apache.org wrote:
On Tue, Feb 2, 2010 at 11:25 AM, Randall Leeds randall.le...@gmail.com
wrote:
I'm not entirely happy with this patch and I'd like some help figuring
out what to do about it.
I foresee problems when database files are
On Feb 2, 2010, at 2:48 PM, Randall Leeds wrote:
On Tue, Feb 2, 2010 at 11:39, Chris Anderson jch...@apache.org wrote:
On Tue, Feb 2, 2010 at 11:25 AM, Randall Leeds randall.le...@gmail.com
wrote:
I'm not entirely happy with this patch and I'd like some help figuring
out what to do about
Seems to be what Merkle trees are for, which would allow for the kinds
of fast-forwarding this thread appears to be discussing. I think
that's essentially (or exactly) what git does, fwiw.
If couchdb tracked replication by a Merkle tree, it would obsolete the
update_seq mechanism?
B.
On Tue,
Hi everybody,
Recently there was a suggestion at #couchdb, involving me, Chris Anderson
and Adam Kocoloski, about the possibility of adding UUIDs to a DB.
It appeared in the context of a future _replications DB (which would store
history about replication sessions, etc). It would not be
can't you make a _local document with your own unique identifier?
_local documents are not replicaed.
B.
On Mon, Feb 1, 2010 at 6:58 PM, Filipe David Manana fdman...@gmail.com wrote:
Hi everybody,
Recently there was a suggestion at #couchdb, involving me, Chris Anderson
and Adam Kocoloski,
On Mon, Feb 1, 2010 at 10:58 AM, Filipe David Manana fdman...@gmail.com wrote:
Hi everybody,
Recently there was a suggestion at #couchdb, involving me, Chris Anderson
and Adam Kocoloski, about the possibility of adding UUIDs to a DB.
It appeared in the context of a future _replications DB
On Tue, Feb 2, 2010 at 4:16 PM, Chris Anderson jch...@apache.org wrote:
UUIDs will be useful for a lot of things. My favorite bug we see now
from not having a uuid, is when you are prototyping an app in the
browser (with a function to generate X random docs for testing):
When you apply the
16 matches
Mail list logo
