Storing rapidly changing data without revision saves

[Ragu Vijaykumar]

Hi,

I'm trying to save rapidly changing data into a CBLModel which has autosave on, as I need it to save as often as it can whenever the data changes. However, I do not need revisions saved everytime I update the model. Is there a way to prevent revisions from being saved (currently, the database size is growing huge due to the large number of revisions when I'm only interested in the most current save), and instead have the same trigger an overwrite of the document? I already set maxRevisionTreeDepth = 1, and know I can compact, but this takes time.

Thanks!

[Jens Alfke]

On Sep 18, 2015, at 3:34 AM, Ragu Vijaykumar <ra...@lumobodytech.com> wrote:

I'm trying to save rapidly changing data into a CBLModel which has autosave on, as I need it to save as often as it can whenever the data changes. However, I do not need revisions saved everytime I update the model.

We’ve brainstormed this a bit, but there’s no ability to do that yet. It gets complex because revisions are by design immutable, so changing a document does require creating a new revision.

Is there a way to prevent revisions from being saved (currently, the database size is growing huge due to the large number of revisions when I'm only interested in the most current save), and instead have the same trigger an overwrite of the document? I already set maxRevisionTreeDepth = 1, and know I can compact, but this takes time.

You could use ForestDB storage instead of SQLite; then the revision-tree compaction is incremental and happens on every save, so you won’t get this bloat.

I don’t know how important replication is to your app, but the frequent pruning of old revision-IDs will lead to false conflicts if multiple clients are updating the same documents. There won’t be enough information in the revision tree to determine whether updates from different clients are part of the same chain or not.

—Jens

[Ragu Vijaykumar]

Is ForestDB ready for production (app-store) ready apps? I thought it was still experimental.

[Ragu Vijaykumar]

Revisions for the particular document are not important to us, as when it is constantly updating with new information, it was only just created and no other users have access to the document until it is done.

On Friday, September 18, 2015 at 10:45:28 AM UTC-7, Jens Alfke wrote:

[Jens Alfke]

On Sep 18, 2015, at 11:21 AM, Ragu Vijaykumar <ra...@lumobodytech.com> wrote:

Is ForestDB ready for production (app-store) ready apps? I thought it was still experimental.

It’s not ready for production yet, but it will be when CBL 1.2 is released, which is about two months away. So it depends on how that fits with your development cycle. In the meantime it’s reliable enough to use during development.

Revisions for the particular document are not important to us, as when it is constantly updating with new information, it was only just created and no other users have access to the document until it is done.

Yes, that’s a common special case that will probably be easier to implement when we add this feature.

—Jens