How can we clean up metadata in "live" documents (not expired or deleted)


#1

Hello,
On our mobile app (ios), we have several documents that are in constant use, they are being modified several times during the day, so I have taken a look on the metadata and I see that some documents are >11,000 lines long! almost all these lines correspond to metadata, and only a dozen, just 12 tiny lines, correspond to our data!
Can anyone please tell me how to clean up the metadata without deleting/purging/flushing/expiring the document??
We are using shadow bucketing as we access info via web and via mobile app.
I appreciate any help,
BR,
Sandra


#2

Reduce the revs_limit property in the Sync Gateway config; that controls the depth of the revision history that SG remembers.

If the metadata contains multiple copies of the document contents itself (not just revision IDs), that means the document has unresolved conflicts. Something (a mobile client or a server-side process using the SG REST API) needs to be detecting and resolving those.


#3

Thank you Jens, is there any recommended value for the revs_limit parameter?
no, they don’t contain copies of the document, just metadata.
Best regards,
Sandra


#4

it depends on how far out of sync you expect clients to get with the server, in terms of number of revisions. 100 is probably reasonable.


#5

Oh oh, our revs_limit is set to 40.
And I took a second look and found copies of the document contents in section “bodymap”.
So, Do you think these unresolved conflicts are giving such huge amount of lines of metadata? (>11,000).
BR, Sandra


#6

Yes, you’ve got conflicts.


#7

Hi @jens, How can I resolve these conflicts from app side.


#8

We have documentation on how to detect and resolve conflicts.


#9

Thank you Jens. Since we use bucket shadowing, we have done a flush on the shadow bucket so that sync gw create a fresh new version from the original bucket and the metadata reduced drastically.
We will of course write code to handle conflicts on both the server side and the application side.
Best regards, Sandra