Hi everyone, thanks for all answers and sorry it took me so long to reply.
I'll go with a combination of replicate and create: 1. determine a list of missing documents in the userdb. 2. replicate those to the user-db using replication by docid. 3. determine missing documents again. 4. create those in the userdb. To get rid of no longer needed documents I use delete. A 2nd daemon will keep the image documents updated from the server using replication. Conflicts occurring from step 4. are easy to resolve, so that's not a problem. Sooner or later almost none of the image documents will get replicated in step 2. but if we cycle (copy non-deleted to a new user-db) the user-dbs regularly these deleted and thus "consumed" ids/revs will disappear. thanks again, Stefan 2014-11-27 11:37 GMT+01:00 Jan Lehnardt <[email protected]>: > > 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 > >> > >> > >
