Devs,
I've been thinking there are a few simple options that would magnify
the power of the replicator a lot.
The simplest one is copy-doc by id. You'd post a JSON list of docids
with your replication definition. Those docs would be copied from the
source to the target. This is technically
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).
On Jan 24, 2010, at 3:09 AM, Chris Anderson wrote:
Devs,
I've been thinking there are a few simple options that would magnify
the power of the replicator a lot.
The simplest one is copy-doc by id. You'd post a JSON list of docids
with your replication definition. Those docs would be
On Fri, Dec 18, 2009 at 20:30, Damien Katz dam...@apache.org wrote:
I think we should set a hard date of Feb 1. for feature freeze, 0.11.0 is the
last new feature release.
Did this ever turn into some kind of consensus, or is there no idea
yet about a 0.11 release time frame?
Cheers,
Dirkjan
Hi,
Folloging suggestion of @jchris I revisited my rewrite handler. This
time instead of using a javascript function to handle rewriting it
uses pattern matching in Erlang to do it. The rewriting root is the
the design doc :
/yourdb/_design/ddocname/_rewrite/
ddocname should contain a
There is something very intriguing about this idea to build a wiki based on
CouchDB. It seems like a perfect match for the database. However, there is a
(somewhat) immediate need for a better functioning wiki. What about just fixing
the existing system? Can we figure out why there are 500
On Sun, Jan 24, 2010 at 4:50 AM, Robert Dionne
dio...@dionne-associates.com wrote:
On Jan 24, 2010, at 3:09 AM, Chris Anderson wrote:
Devs,
I've been thinking there are a few simple options that would magnify
the power of the replicator a lot.
The simplest one is copy-doc by id. You'd
On Sun, Jan 24, 2010 at 8:03 PM, Brian Chamberlain
blchamberl...@gmail.com wrote:
There is something very intriguing about this idea to build a wiki based on
CouchDB. It seems like a perfect match for the database. However, there is a
(somewhat) immediate need for a better functioning wiki.
It's somewhat ironic that the couch wiki has a link to a couchapp wiki server -
http://code.google.com/p/tapirwiki
I've given it a whirl, and while I might quibble with some of the design
decisions, it's quite ok as a start. Don't yet know if it's a suitable
launching point for a large-scale
I've been trying to eliminate, or at least vastly reduce the need for
middleware in a specific class of applications, but this problem probably cuts
that task short.
We have incoming documents that need to be validated against data stored in
other docs (rate tables, technical abbreviations,
On Sun, Jan 24, 2010 at 12:09 AM, Chris Anderson jch...@apache.org wrote:
Devs,
I've been thinking there are a few simple options that would magnify
the power of the replicator a lot.
...
The fun one is chained map reduce. It occurred to me the other night
that simplest way to present a
On Sun, Jan 24, 2010 at 2:04 PM, Glenn Rempe gl...@rempe.us wrote:
On Sun, Jan 24, 2010 at 12:09 AM, Chris Anderson jch...@apache.org wrote:
Devs,
I've been thinking there are a few simple options that would magnify
the power of the replicator a lot.
...
The fun one is chained map reduce.
[
https://issues.apache.org/jira/browse/COUCHDB-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Manana updated COUCHDB-583:
--
Attachment: couchdb-583-trunk-15th-try-git.patch
Just added a missing caseless option to the
That's exactly what creates the high associated procedure cost - the documents
are submitted by mobile workers who connect for very short times, sometimes
very infrequently. If the document is accepted with invalid entries and
processed later, the opportunity to alert the author of the
On Sun, Jan 24, 2010 at 2:25 PM, David Richardson techni...@enquora.com wrote:
That's exactly what creates the high associated procedure cost - the
documents are submitted by mobile workers who connect for very short times,
sometimes very infrequently. If the document is accepted with invalid
[
https://issues.apache.org/jira/browse/COUCHDB-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12804331#action_12804331
]
michael h commented on COUCHDB-326:
---
This issue still exists in the windows binary
On Sun, Jan 24, 2010 at 8:16 PM, Glenn Rempe gl...@rempe.us wrote:
On Sun, Jan 24, 2010 at 2:11 PM, Chris Anderson jch...@apache.org wrote:
On Sun, Jan 24, 2010 at 2:04 PM, Glenn Rempe gl...@rempe.us wrote:
On Sun, Jan 24, 2010 at 12:09 AM, Chris Anderson jch...@apache.org
wrote:
Devs,
On Sun, Jan 24, 2010 at 5:28 PM, David Richardson techni...@enquora.com wrote:
I'm wary of the procedural-controller middleware approach because I'm
afraid it encourages you to program as though you have transactions.
(Eg: change these 4 documents at the same time and hope for the best.)
I
On Sun, Jan 24, 2010 at 11:00 AM, Benoit Chesneau bchesn...@gmail.com wrote:
Hi,
Folloging suggestion of @jchris I revisited my rewrite handler. This
time instead of using a javascript function to handle rewriting it
uses pattern matching in Erlang to do it. The rewriting root is the
the
19 matches
Mail list logo
