try hood.ie :-) Em Wed Nov 26 2014 at 12:40:11 PM, Conor Mac Aoidh <[email protected]> escreveu:
> Hi Stefan, > > I have a similar setup - individual user database which are filter > replicated to a main database and also to pouchdb in the client. > > I ran into a similar issue also of keeping the user databases (and pouch > dbs) clean. The server side logic consists of tracking user sessions > with a daemon, and then when a user is known to be inactive run a > compaction on their db. In pouch, instead of cleaning the db and > creating a new one, I opted as much as possible to use API calls (to the > server application, not couch) to fetch data that would likely expire. > This does however deviate from a pure-couch way of doing things. I would > be interested to know if you come up with other alternatives! > > Thanks > > Conor > > On 25/11/14 20:51, Sebastian Rothbucher wrote: > > 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 > >> > >
