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
On Friday, January 30, 2015 at 2:48:55 PM UTC-8, Hadi Sharghi wrote:
>
> 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
>
>
>
>
> On Saturday, January 31, 2015 at 1:48:56 AM UTC+3:30, Adam Fraser wrote:
>>
>> 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
>>
>>
>> On Friday, January 30, 2015 at 2:07:41 PM UTC-8, Hadi Sharghi wrote:
>>>
>>> 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
>>>
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/mobile-couchbase/9b5f6510-7829-44a3-b10f-4da3ba4a7483%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
