CouchDB: database has many deleted docs on server

[Chris Ju]

Hi,

there is an issue with one database (of many databases i use with CouchDB sync), please see screenshots. I don’t know if it is really an issue, but with this database entered data often just disappear after sync. All other databases doesn’t have this notice on the server.

I already deleted the database on the server, ran maintenance in Tap Forms and synced again. Nothing helped…

Does anyone have a hint for that issue?

Thanks
Chris

Attachments:

You must be logged in to view attached files.

[Sam Moffatt]

You need to run compaction on the CouchDB server and it’ll purge the records. It should happen automatically though likely the trigger hasn’t happened because it’s not that bad yet or maybe you have a 2.x era configuration that needs updating for 3.x release. Checkout the CouchDB documentation on compaction for more details but realistically I don’t think it’s inherently problematic. It’s just reflecting that you’ve created and deleted a lot of stuff (including fields per your sample image) and eventually that will go away once you start populating data more consistently (unless of course you have a flow that regularly deletes records).

[Chris Ju]

Thanks, Sam. What puzzles me is that I deleted the database from the server. After I compacted the database several times in Tap Forms and then synchronized it with the server again, the deleted docs are there immediately. Doesn’t Tap Forms remove deleted documents on running “Compact Database”? Or could it be, that the database (the entries) on the server will not be deleted really at all if I delete the database on the server? The name of the database is then the same again.

Could it be, that the Tap Forms database is corrupted?

I’m using CouchDB sync with Synology/Docker. Do you know how to ssh to couchdb server to be able to run the “compacting program” for a certain database?

[Sam Moffatt]

TF will sync the tombstones for deleted documents and generally compaction doesn’t immediately remove these because otherwise how does it know it’s deleted? It’s part of the distributed sync so that if someone changes a record that has been deleted that triggers a conflict that has to be resolved. Now I think of it more, there is another purge API for removing tombstones but its a little harder to use.

I don’t think the TF database is corrupt, it’s probably working as expected, especially if this is a scratch document you’ve created and deleted records, forms and fields in.

No idea how Synology’s stuff works, presumably if they have an SSH connection you can then use docker exec -it <container name> /bin/bash to get a shell in the container but all of the CouchDB stuff is available via their REST API.

[Author]

Posts