On Tue, 28 Apr 2020, at 07:06, Andrea Brancatelli wrote:
> Hello Robert,
>
> I see your point and mostly understand it. The plan was not to "use"
> this secondary database as an active one, but as a passively replicated
> database from a main instance, so performances of the secondary database
>
Thanks, I appreciate it a lot.
I'm forwarding your code to our pouch-eous guys :-)
---
Andrea Brancatelli
Schema31 S.p.a.
On 2020-04-28 15:30, Joel Jucá wrote:
> Andrea,
>
> Just like Robert and Garren said, CouchDB is not designed to work this way.
> But I'm thinking of an architecture on
Andrea,
Just like Robert and Garren said, CouchDB is not designed to work this way.
But I'm thinking of an architecture on top of it:
You could, for instance, create document versions that point to their
ancestors. This way you would create a tree of versions (it's necessary if
you want to
Noting a) that replication only replicates latest revision, not the older ones.
b) compaction is not optional, you are strongly advised not to go this way.
--
Robert Samuel Newson
rnew...@apache.org
On Tue, 28 Apr 2020, at 11:46, Garren Smith wrote:
> I think it would be better to create a
I think it would be better to create a daily or hourly snapshot of your
database instead of relying on a database that doesn't run compaction.
Depending on the versioning history of a CouchDB database is a really bad
idea.
As Bob said, rather create new docs than one document with lots of
Hello Robert,
I see your point and mostly understand it. The plan was not to "use"
this secondary database as an active one, but as a passively replicated
database from a main instance, so performances of the secondary database
weren't a big priority - the idea is to keep the whole "journal" of
Hi,
This is the most common mistake made with CouchDB, that it provides (or could
provide) a full history of document changes.
Compaction is essential, it's the only time that the b+tree's are rebalanced
and obsolete version of b+tree
nodes are removed from disk.
If the old revisions of your
Let's say I'd like to keep the whole revision history for documents in a
specific database (but maybe drop old views, if it's possible).
What compaction setting would do that overriding the more-reasonable
default we usually have?
--
Andrea Brancatelli
