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
