OK, thanks for clarifying that. Best, Hadi
On Saturday, January 31, 2015 at 2:43:59 AM UTC+3:30, Adam Fraser wrote: > > 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/44719456-32d9-416a-9f47-3c5ab29d70be%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
