Store last revision straight into the object

[Petros Moisiadis]

Hello,

I was wondering if it is possible somehow to store the last revision in which an object was part of straight into that object. The use case is to synchronize multiple users trying to edit the same object, so that if one user tries to send an updated object with a last revision id that is not the same as the one stored in the database, it would mean that another user has previously edited the object, so the system can act appropriately (e.g. deny the update or warn the user, etc.). Since the object is already in 'revision control' through reversion, it makes sense to use that info and not have another field doing that job. Also, I know that I can get the last revision indirectly from the Revision model, but I want it to be straight into the object for performance reasons.

That said, the above seems impossible because, if I am right, the revision is created after the object has been saved, so it can't be added to the object without saving it again, which would in turn cause a new revision to be created. So, I am thinking that it would be handy if there was an easy way to control whether save() on an object would create a new revision. E.g. if calling save() within a 'no_revision' decorator it would not add the object to the revision. That way I could call save twice, one for creating the revision and another one just for saving the last revision into the object without creating a new revision.

Another approach would be to use reversion's pre_revision_commit signal and calculate some hash that is unique for the revision being commited (e.g. derived from revision's timestamp + some random string), but I would prefer to have the actual last revision saved into the object.

Any thoughts on this?

[Dave Hall]

The way this is normally done is that you'd include the ID of the latest revision in the user's form data. When they submit the form, if the revision id is no longer the latest, you give them an error.

No database effort needed!

--
You received this message because you are subscribed to the Google Groups "django-reversion discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-reversi...@googlegroups.com.
To post to this group, send email to django-r...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-reversion.
For more options, visit https://groups.google.com/d/optout.

[Petros Moisiadis]

On Thursday, December 3, 2015 at 12:50:31 PM UTC+2, Dave Hall wrote:

The way this is normally done is that you'd include the ID of the latest revision in the user's form data. When they submit the form, if the revision id is no longer the latest, you give them an error.

No database effort needed!

I want to avoid the performance cost of getting the latest revision each time I get the object, as well as doing that for each object in list views with many objects.

 

[Dave Hall]

A single database query to retrieve a single integer value isn't going to add much overhead to your request. :P

Alternatively, store a uuid on the object whenever it saved, and put that in the form data to check for conflicts.

--