Sync Gateway REST API expiration

[Hadi Sharghi]

Hi,

I'm using Sync Gateway REST API to update documents from a website, When I update a document and a previous revision is created, it has an expiration value like this "1422654390" and the revisions are getting disappear after a while. I couldn't figure out:

1- Why REST API sets an expiration on revisions and what does this number means? It's a date-time format? milliseconds from the moment revision is created?

2- If it's possible, how can I set the expiration manually or set to never or a month instead of couple of minutes?

Regards,

Hadi Sharghi

 

[Adam Fraser]

This sounds like the automated expiration of obsolete revisions.  Currently obsolete revisions are set to automatically expire after five minutes, instead of requiring manual compaction.  More details can be found here: https://github.com/couchbase/sync_gateway/issues/372.

At the time there was some discussion of making the expiration time configurable, but there wasn't a pressing use case.  If you can share some details about your use case, it would be helpful.

Thanks,
Adam

[Hadi Sharghi]

Thanks, but what's the point of having revisions if they are going to be there for only 5 minutes? The only use for this would be undoing update within the 5 minute time-out. 

I'm working on a project in which persons in teams are going to produce some data of on observation. In any team there are people to check the observations and update the stored data if they see any difference. I'm not sure if I could make myself clear, so I give you an example:

1- team x stores a doc:

{

    "id": "02c2c68f-1f63-4c5b-b705-6e77654aac5d",

    "key": "2015-01-30T14:57:24.767Z",

    "value": 

    {

        "created_at": "2015-01-30T14:57:24.767Z",

        "type": "polev12",

        "latitude": 30.281420999999998,

        "longitude": 57.08313,

        "teamID": "45",

        "teamName": "team x",

        "projectID": "132",

        "projectName": "project y",

        "model_data": "{\"connectionsProps\":{\"nameValuePairs\":{}},\"consoleProps\":[{\"cableMV_on_console_Props\":{\"nameValuePairs\":{}},\"consoleProps\":{}},\"arayeh\":0,\"console_rotation\":0,\"console_type\":0,\"wire_or_cable\":0}],\"poleProps\":{\"nameValuePairs\":pole_aashkarsaze_khata.json5\":\"{}\",\"pole_autobooster.json6\":\"{}\",\"pole_rabet_mv.json7\":\"{}\",\"pole_sarkabl_mv.json8\":\"{}\",\"pole,post_earth_props.json9\":\"{}\",\"pole,post_khazen_props.json10\":\"{}\",\"post,pole_sectioner_props.json11\":\"{}\",\"console_tajhizat.json12\":\"{}\",\"tozih.json13\":\"{}\"}},\"num_consoles\":3,\"latitude\":30.281420999999998,\"longitude\":57.08313,\"real_gps_accuracy\":10.0,\"real_gps_latitude\":30.283374,\"real_gps_longitude\":57.0834681,\"isRealGpsPoint\":false,\"cur_revision_id\":\"1-3f6dd2be14c65165f4197f0d71ba3f43\",\"recordType\":\"polev12\",\"session_guid\":\"4787f782-1d21-4eef-b11c-5252a44b2381\"}"

    }

}

2- User x sees some mistakes in data_model and revise the document and modifies the model_data

3- Admin has to check if teams had any revisions, if so what was the cause of having a revision. So admin have to see all the revisions and fill out some forms about the revised data

 

But Admin doesn't have access to document's revisions because they are already expired.

This is my use case and I think it's a simple case that should be able to handle with versioning, but it seems not.

Regards,

Hadi

[Adam Fraser]

Revisions aren't intended to act as a version control system - they are the means to provide conflict handling for multiple writers.  This is covered in the documentation:

http://developer.couchbase.com/mobile/develop/guides/couchbase-lite/native-api/revision/index.html

In particular this excerpt is relevant to your scenario:

Keep in mind that Couchbase Lite is not a version control system and you must not use the versioning feature in your application (for example, you can’t use it to store the revision history of pages in a wiki). The old revisions are just cached—they are periodically thrown away when the database is compacted, and they’re never replicated. They’re not there to use in your data model, they’re there only to help with concurrency and resolving conflicts during replication.

For the use case you describe, there are probably a few ways to make it work without relying on Couchbase Lite's internal revisions, depending on how you manage the workflow in step 2 ("User x sees some mistakes in data_model...."), and how much information the Admin needs about the old version in step 3. Based on that you can decide whether you need to maintain the full change history (in which case you'd need to make a copy of the old version at step 2), a partial history (write a change log at step 2), or just knowing whether a document has been changed by someone other than the original author (could be managed as a property within the document itself).

Adam

[Jens Alfke]

On Jan 30, 2015, at 2:07 PM, Hadi Sharghi <hsha...@gmail.com> wrote:

I'm using Sync Gateway REST API to update documents from a website, When I update a document and a previous revision is created, it has an expiration value like this "1422654390" and the revisions are getting disappear after a while.

What do you mean by "an expiration value"? Where exactly do you see this number? (The only place I think this would be visible is through the Couchbase Server APIs; generally you shouldn't be looking at the gateway's internal bucket.)

As Adam said, you cannot rely on bodies of previous revisions of a document being preserved. They're only kept in order to help conflict resolution and to handle race conditions with clients. The same goes for all databases of this type, including Couchbase Lite, CouchDB, PouchDB, Cloudant, etc.

—Jens

[Hadi Sharghi]

OK, thanks for clarifying that.

Best,

Hadi

[Hadi Sharghi]

I'll see that in 'meta' section of a document in Couchbase admin panel (:8091), in Views section.