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 > >
