Heya Jason, not sure this works if you have two way replication, because then the server gets the delete and there is nothing to bump.
Best Jan -- > On 26 Nov 2014, at 15:51 , Jason Smith <[email protected]> wrote: > > Hi, Jan. I'm sure you know this already, but to me, the current solution is > also the correct one. > > The user deleted some information. The server has the old version. But now > the user needs it again. > > Each of the sentences above seems to me like a bit of useful information in > the application. And so it's reasonable that each one is a revision to the > document. > > In other words: "bump" or "touch" your document so it will re-replicate > down. This may be a good time to keep a timestamp or something else. Yes > you have to do some work yourself, but it kind of makes sense if you look > at it a certain way :) > > On Tue, Nov 25, 2014 at 8:24 PM, Jan Lehnardt <[email protected]> wrote: > >> 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 >> >>
