couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: A elegant way around purging documents?
Date Tue, 25 Nov 2014 20:24:16 GMT
Heya Stefan,

just a quick note: Purge is definitely the wrong approach.

I’ve been trying to solve something similar recently for a client
and we didn’t come up with a conclusive solution. I’d love for CouchDB
and PouchDB to natively support this use-case, but this is currently
not possible as per the design of CouchDB.

Would you be interested in opening a ticket so we can discuss this
with the developers? https://issues.apache.org/jira/browse/COUCHDB

The project ended up deleting client-side databases to free space
followed by a re-sync of only the “current” parts. It worked for
the setup, but that’s by far not generally applicable, let alone
a satisfactory solution.

Best
Jan
--



> On 25 Nov 2014, at 15:18 , Stefan Klein <st.fankl.in@gmail.com> wrote:
> 
> Hi couch users,
> 
> I got a main database and a database per user.
> A users Db is replicated to his device (mobile phone) - idea is as much
> functionality should be available offline.
> 
> To simplify a bit, let's say i got documents of type "item" and of type
> "image", each "item" may reference multiple "images" and each "image" may
> be referenced by multiple "items".
> When a user gets a new "item" from the main database, a daemon checks if
> all referenced images are available for that user and triggers replication
> of the images missing.
> If a user still got images which aren't needed on his device anymore, i
> want to delete them, why waste space on his device?
> 
> Here comes my problem:
> Say he got the document "image1" in revision: "1-abc" and doesn't need it
> anymore i will delete it, which creates {_id: 'image1', rev: '2-cde',
> _deleted: true} if for some reason he needs "image1" again because it is
> also referenced by a different "item" i will replicate {_id: 'image1', rev:
> '1-abc', ./*.. */} from the main database to the users database again. The
> users database "says" i know an ancestor of that document the revision
> "2-cde" in that example and the document "image1" will not show up again.
> 
> One way to solve that by attaching the images directly to the "items" - but
> we got ~7 million items sharing ~4000 images, so that would increase the db
> size by much.
> 
> An other way is using purge to delete an image so it can be replicated
> again, but it seams to be wrong to use purge for general application logic,
> think it should be kind of last resort.
> 
> Any other ideas?
> 
> Thanks & regards,
> Stefan


Mime
View raw message