Hi Stefan,
as you delete per User-DB only, can you also CREATE per User-DB only. This
way, you'd lose replication as a feature, but why not have a different
Doc-ID and storing the original doc-ID in some field (so _id=123 on the
central DB would become _id=345, originalid=123 on the user's DB).with a
custom index, you can retrieve again. You'd never replicate the
user-specific image documents and you can do whatever you like. I don't
know how probable it is for an image getting deleted and then re-added, but
it can hardly be more probable than getting another image alltogether.
Good luck - and let us know!
Sebastian
On Tue, Nov 25, 2014 at 9: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
>
>
