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 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 revisions. > PouchDB is slow to replicate documents with lots of revisions versus lots of > new documents. > > Cheers > Garren > > > > On Tue, Apr 28, 2020 at 9:06 AM Andrea Brancatelli > <abrancate...@schema31.it.invalid> 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 >> weren't a big priority - the idea is to keep the whole "journal" of the >> main database. >> >> We thought of having multiple copies of the documents as well, but the >> "client" is a React/Pouch application and that would become a pita. >> >> My plan was to have a main database with a very aggressive compaction >> rule, so that pouch replication would be as fast as possibile and the >> local storage be as little as possible (also because pouch isn't blazing >> fast with local views and indexes when you have a lot of documents) and >> a secondary replicated database with a more relaxed compaction rule (as >> I was saying maybe disabled at all) to run backups on or to do >> post-mortem analysis of any problem that may rise on business logic. >> >> --- >> >> Andrea Brancatelli >> >> On 2020-04-27 20:34, Robert Samuel Newson wrote: >> >> > 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 documents really matter, make new documents >> instead of updating them, and use some scheme of your choice to group them >> (you could use a view on some property common to all revisions of >> > the same logical document). >> > >> > B. >> > >> >> On 27 Apr 2020, at 17:10, Andrea Brancatelli >> <abrancate...@schema31.it.INVALID> wrote: >> >> >> >> 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
