1/31/2024 0 Comments Sqlitestudio manualTombstoned documents are not automatically purged on the client.Homework Instructions The deliverable must include a script that creates and populates all the tables as explained below in the list of requirements. Queries on lite client will not return the deleted documents. ![]() So that’s why the tombstoned documents get replicated to the client. īased on your observations, I am going to assume that you have shared_bucket_access enabled. This is different from pre-convergence case wherein expired documents are purged and in that case, as Jens indicated, purged docs wouldn’t get replicated. (The tombstoned documents eventually get purged based on the metdata_purge_interval that’s set on the server). In case of tombstoned documents, the metadata corresponding to the document exists but there is no document body. Under convergence (shared_bucket_access is enabled), expired documents are tombstoned. Are the documents on server set to expire on the server using TTL mechanism? Just to confirm what you are seeing and to level set on terminology. …We are correctly receiving the expired docs via replication but, even thought we correctly purge, compact and close the db Well, we set expiration on documents server side and they are indeed replicated to the clients. Have you used the explain method to check your queries? This could be a sign that you don’t have effective indexes, as a linear database scan will definitely get slow as the db grows, especially on devices with slow storage. Oh also, 140MB isn’t that big, so I wouldn’t expect queries to get too slow. (The database is put in auto_vacuum=incremental mode when created.) This should shrink the file if there are unused pages.Ĭheck the logs for a message Vacuuming database if you don’t see that, maybe the actual compact method isn’t being reached for some reason. Compacting the database runs a SQLite PRAGMA optimize and PRAGMA incremental_vacuum. So the document will be purged on the server, but clients that already had the document won’t be affected they still have it. SQlite file size after compacting using SQLITE Studio -> ** 119234239**ĭocuments are set to expire on server ( VIA NOD JS) but the Client (IOS, SWIFT, CBL 2.6) doesnt delete them from diskĮxpiration is not replicated: An expiration time you set on server is not propagated to clients. SQlite file size after compacting using the couchbaselite db.close() function -> ** 144949248** SQlite file size after compacting using the couchbaselite db.compact() function -> ** 149126768** (DID NOTHING) SQlite file size before compacting using the couchbaselite function -> ** 149126768** SQlite file size after compacting using the couchbaselite db.close() function -> 144949248 SQlite file size after compacting using the couchbaselite db.compact() function -> 149590016 (DID NOTHING) ![]() SQlite file size before compacting using the couchbaselite function -> 149590016 ![]() The result is a Sqlite file size that keeps sky rocketing resulting in poor performance. We also tried manually deleting and purging docs manually, but the SQLIte db doesnt shrink in size.ĭocuments are set to expire on server ( VIA NOD JS) but the Client (IOS, SWIFT, CBL 2.6) doesnt delete them from disk even tho purge and compact are called. Now it’s over 140mb resulting in a ridicolously bad performance when querying on older devices (like ipad mini 2). We are correctly receiving the expired docs via replication but, even thought we correctly purge, compact and close the db, the SQLite database keeps growing. We set( via the NODE.js SDK) an expire date to 1 week for every docoument to keep the iOS Client clean and fast. Hi, we have a database with about 150.000 documents, growing every week by 5k docs.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |