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 <[email protected]> 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
