couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dale Harvey <d...@arandomurl.com>
Subject Re: final long term deletion,cleanup database, and id generation
Date Tue, 31 May 2016 15:26:54 GMT
Does mango share the same disadvantages as map reduce with indexes having
to be rebuilt on purge? In PouchDB it currently does however we are looking
to change the pouchdb-find implementation so that purge has no negative
effect on the query performance, at which point we will implement and be
happy pointing users towards using purge (with the caveats about their
affect on replication).

With PouchDB we have to be very aware about keeping local disk size to a
minimum and recommending to users that they replicate to new databases in
order to save disk size is not user friendly imo, so we are definitely
interested in looking at ways to improve disk space usage. Moving purge
away from 'avoid this' territory is one way.

On 31 May 2016 at 16:12, Stefan Klein <st.fankl.in@gmail.com> wrote:

> Hi,
>
> 2016-05-31 17:00 GMT+02:00 david rene comba lareu <
> shadow.of.soul08@gmail.com>:
>
> > HI,
> >
>
> [ ... ]
>
>
> >
> > 1) when you delete a document, is supposed that revisions are only
> > deleted after the cleanup, but the tombstones are still there, and it
> > increase the amount of size exponentially. i found this post about it:
> >
> >
> http://eclipsesource.com/blogs/2015/04/20/how-to-finally-delete-documents-in-couchdb/
> > with a sort of solution, that i find tricky and insecure. i don't want
> > be manipulating live DB's on live servers. any other option?
> >
>
> I haven't double checked, but if i remember correctly purging 2 documents
> will cause all views to be re-created.
> Purge is really not to be meant for normal operation.
>
> So the replication of non deleted documents to a new DB is - to my
> knowledge - the only option.
>
> Do you have a proxy in front of your couchdb?
> If so, you do not even need to shut down and copy DB files, but you could
> simply point the proxy to the new DB.
> Remember to refresh the views before switching DBs.
>
> --
> Stefan
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message