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/432aaeaa-e1aa-48ff-b3fa-25235b92e558%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
