You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Stefan Klein <st...@gmail.com> on 2014/11/25 15:18:10 UTC
A elegant way around purging documents?
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
Re: A elegant way around purging documents?
Posted by Stefan Klein <st...@gmail.com>.
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 <ja...@apache.org>:
>
> 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 <ja...@gmail.com> 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 <ja...@apache.org> 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 <st...@gmail.com> 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
> >>
> >>
>
>
Re: A elegant way around purging documents?
Posted by Jan Lehnardt <ja...@apache.org>.
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 <ja...@gmail.com> 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 <ja...@apache.org> 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 <st...@gmail.com> 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
>>
>>
Re: A elegant way around purging documents?
Posted by Jason Smith <ja...@gmail.com>.
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 <ja...@apache.org> 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 <st...@gmail.com> 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
>
>
Re: A elegant way around purging documents?
Posted by Gabriel Mancini <ga...@gmail.com>.
try hood.ie :-)
Em Wed Nov 26 2014 at 12:40:11 PM, Conor Mac Aoidh <co...@gmail.com>
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 <ja...@apache.org> 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 <st...@gmail.com> 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
> >>
>
>
Re: A elegant way around purging documents?
Posted by Conor Mac Aoidh <co...@gmail.com>.
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 <ja...@apache.org> 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 <st...@gmail.com> 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
>>
Re: A elegant way around purging documents?
Posted by Sebastian Rothbucher <se...@googlemail.com>.
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 <ja...@apache.org> 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 <st...@gmail.com> 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
>
>
Re: A elegant way around purging documents?
Posted by Jan Lehnardt <ja...@apache.org>.
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 <st...@gmail.com> 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