couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Fauxton Tidings
Date Fri, 21 Jun 2013 13:35:37 GMT

On Jun 21, 2013, at 14:16 , Adam Kocoloski <kocolosk@apache.org> wrote:

> On Jun 21, 2013, at 7:58 AM, Jan Lehnardt <jan@apache.org> wrote:
> 
>>> Step two is build out a proper interface around the _replicator
>>> database, allowing you to create new persistent replications,
>>> introspect existing replications, look at historic replications, and
>>> also to visually expose the powerful advanced options of the new
>>> replicator allowing higher throughput replications.
>>> 
>>> What kinds of interfaces sounds useful for interacting with the
>>> replicator database? What would you find useful for creating and
>>> managing replications through Fauxton?
>> 
>> While a bit oblique in implementation, I like the git “remote” concept
>> and I think it makes sense in the CouchDB context. Whether a remote
>> is another CouchDB installation and databases are “branches” (in git lingo)
>> or whether a database is a remote is up to decision, but I’d like
>> to be able to configure a set of remotes for my current server (manually
>> and automatically) and then start/stop/schedule/observe replication
>> between the local couch and a “remote”, or two “remotes”, or whatever
>> else makes sense.
> 
> Co-opting the git parlance could work well.  For my money the right analogy is that a
CouchDB server is a remote and databases take the place of repos.  Branching happens at the
granularity of a document, not a database, and replication pushes all branches of all documents
in the database to the remote.

I didn’t make this very clear, maybe I have a simplified concept of git remotes in my head.
I don’t think git server / repos are a useful analogy, because most people start out at
the repo level and then down. Remotes are just locations for a repo (you know this).

What I did not have in mind is a semantic analogy as you describe (which is totally valid!),
I was coming from my usage of git remote:

    git remote add remote-name url
    git fetch remote-name

After which remote-name/branches are available to me. My correlation of databases and branches
is purely on the ”what is on the top level of a remote”.

A CouchDB remote could be another CouchDB server and a fictional `couch remote add remote-name
url` would make `remote-name` available for further operations, e.g. `couch replicate db-name
remote/db-name` (read git push <localbranch> <remote-branch> note that git lists
the remote first in reality, but I want to express a from-to relationship so I can also say:
`couch replicate remote/db-name db-name` to pull changes from the remote db). `couch list
remote-name` would give me list of databases available on the target server etc.

Alternatively a CouchDB remote could be the location of a database anywhere identified with
an URL. (the concept of remotes as proxies for branches took a while for me to grok when learning
git, so maybe we can simplify this in the context of CouchDB:

    couch remote add remote-db-name url
    couch replicate local-db-name remote-db-name

Or the reverse:

    couch replicate remote-db-name local-db-name

Listing databases on another server would be out of band for this model.


But maybe that is confusing and your approach is better because it also has a semantic mapping
of operations further down, but I hope this shows where my thinking came from.

All I really wanted here is see if we could make things simpler for our users and that there
is some work to be done :)

Best
Jan
--








Mime
View raw message