Hello!

Currently exception is thrown when one tries to register a proxy model. Advice is to register a parent class.

But django emits post_save signal with a proxy model class as a sender (not a parent class) so _post_save_receiver is omitted and thus a version/revision is lost.

Why exactly we may want to restrict proxy-model registration?

It works for me if I register both parent and proxy-child (assuming that I've commented out raise RegistrationError(..)).

Issue: Django version: 1.9.7 django-reversion version: 2.0.5 I was using django-reversion 1.8.0, and there is no "db" columns in reversion_version table. Now I am upgrading to version 2.0.5, it adds the column "db" in migration 3, but since there is also a squashed migration file there, when I run python manage.py migrate --fake-initial, it will fake the squashed migration and ignore all the other migrations in the folder, and the migration 2,3,4 will never be ran, so "db" column will not be added to the existing reversion_version table.

Suggested solution: Remove squashed migration.

Thanks.

Use case: model and a sub model, both are proxies, created and edited via admin using inline, Problem: The history view show only changes done to the parent model. in other terms: Recorded changes for proxy models within inlines are not visible on the history view

During investigation, i noticed in the version table, changes recorded foreignkey content_type to concrete model. (changes in parent proxy are recorded pointing to concrete model, same with the child model) while in django_admin_log -as example- , changes (in parent or child) are recorded pointing to the parent proxy model, which makes it easier to retrieve.

How can i go about solving the Problem? any hints where to start ?

Hi,

I'm trying 1.9.3 and I get this exception when trying to revert a document:

NoReverseMatch: Reverse for 'app_list' with arguments '('',)' and keyword arguments '{}' not found. 1 pattern(s) tried: [u'admin/(?P<app_label>hardware|profiles|layers|participation|mailing|net|default|nodes|links|cms|auth|connectors|notifications|metrics)/$']

It seems that the template gets a call like reverse('admin:app_list', args=[], kwargs={}, current_app=None) and this causes the exception.

I do not understand if there is something I have to change in my app in order to upgrade to 1.9.3 or if it might be a bug in django-reversion.

What do you think?

Best regards Federico

Hi!

my reversioned model contains a DateField called "date". Django-reversion used to, and still does, work fine with that model if the serialized_data is xml. With json serialized_data it fails: see exception added below, reproduced in manage.py shell.

I narrowed down the problem to wrong json data: django-reverison produces a revision whith json serialized_data which contains "date": "2011-05-05 00:00:00". So if i change that to "date": "2011-05-05" everything's back to normal.

/path/to/latest/reversion/models.pyc in get_object_version(self)
    187         if isinstance(data, unicode):
    188             data = data.encode("utf8")
--> 189         return list(serializers.deserialize(self.format, data))[0]
    190 
    191     object_version = property(get_object_version,

/usr/lib/pymodules/python2.7/django/core/serializers/json.pyc in Deserializer(stream_or_string, **options)
     33     else:
     34         stream = stream_or_string
---> 35     for obj in PythonDeserializer(simplejson.load(stream), **options):
     36         yield obj
     37 

/usr/lib/pymodules/python2.7/django/core/serializers/python.pyc in Deserializer(object_list, **options)
    126             # Handle all other fields
    127             else:
--> 128                 data[field.name] = field.to_python(field_value)
    129 
    130         yield base.DeserializedObject(Model(**data), m2m_data)

/usr/lib/pymodules/python2.7/django/db/models/fields/__init__.pyc in to_python(self, value)
    609 
    610         if not ansi_date_re.search(value):
--> 611             raise exceptions.ValidationError(self.error_messages['invalid'])
    612         # Now that we have the date string in YYYY-MM-DD format, check to make

    613         # sure it's a valid date.


ValidationError: [u'Enter a valid date in YYYY-MM-DD format.']

ERROR: testRecoverDeleted (reversion.tests.FollowModelsTest)

Traceback (most recent call last): File "/Users/djangodeveloper/virtual_environments/ngc/lib/python2.7/site-packages/reversion/tests.py", line 466, in testRecoverDeleted reversion.get_deleted(ReversionTestModel1)[0].revision.revert() File "/Users/djangodeveloper/virtual_environments/ngc/lib/python2.7/site-packages/reversion/models.py", line 90, in revert do_revert([version for version in version_set if version.type != VERSION_DELETE]) File "/Users/djangodeveloper/virtual_environments/ngc/lib/python2.7/site-packages/reversion/models.py", line 83, in do_revert version.revert() File "/Users/djangodeveloper/virtual_environments/ngc/lib/python2.7/site-packages/reversion/models.py", line 286, in revert self.object_version.save() File "/Users/djangodeveloper/virtual_environments/ngc/lib/python2.7/site-packages/django/core/serializers/base.py", line 165, in save models.Model.save_base(self.object, using=using, raw=True) File "/Users/djangodeveloper/virtual_environments/ngc/lib/python2.7/site-packages/django/db/models/base.py", line 570, in save_base created=(not record_exists), raw=raw, using=using) File "/Users/djangodeveloper/virtual_environments/ngc/lib/python2.7/site-packages/django/dispatch/dispatcher.py", line 172, in send response = receiver(signal=self, sender=sender, **named) File "/Users/djangodeveloper/virtual_environments/ngc/lib/python2.7/site-packages/reversion/revisions.py", line 566, in _post_save_receiver version_data = adapter.get_version_data(instance, VERSION_ADD) File "/Users/djangodeveloper/virtual_environments/ngc/lib/python2.7/site-packages/reversion/revisions.py", line 106, in get_version_data "serialized_data": self.get_serialized_data(obj), File "/Users/djangodeveloper/virtual_environments/ngc/lib/python2.7/site-packages/reversion/revisions.py", line 90, in get_serialized_data fields = self.get_fields_to_serialize(), File "/Users/djangodeveloper/virtual_environments/ngc/lib/python2.7/site-packages/django/core/serializers/init.py", line 91, in serialize s.serialize(queryset, **options) File "/Users/djangodeveloper/virtual_environments/ngc/lib/python2.7/site-packages/django/core/serializers/base.py", line 48, in serialize self.handle_fk_field(obj, field) File "/Users/djangodeveloper/virtual_environments/ngc/lib/python2.7/site-packages/django/core/serializers/python.py", line 48, in handle_fk_field related = getattr(obj, field.name) File "/Users/djangodeveloper/virtual_environments/ngc/lib/python2.7/site-packages/django/db/models/fields/related.py", line 315, in get rel_obj = QuerySet(self.field.rel.to).using(db).get(**params) File "/Users/djangodeveloper/virtual_environments/ngc/lib/python2.7/site-packages/django/db/models/query.py", line 349, in get % self.model._meta.object_name) DoesNotExist: ReversionTestModel1 matching query does not exist.

Hi,

I have a model (my_model) with foreignkeys with "on_delete" set to "models.PROTECT". my_link = models.ForeignKey(my_other_model, on_delete=models.PROTECT, null=True, blank=True) If I create a my_model and dont set my_link, then reversion works fine. But if I set my_link to actually link to an instance of my_other_model then I get the following error when I try to look at a reversion history instance in the admin view. E.g going to: http://127.0.0.1:8000/admin/my_app/my_model/1/history/1/ gives: Internal Server Error: /admin/my_app/organism/1/history/1/ Traceback (most recent call last): File "/home/my_user/.pyenv/versions/3.8.0/envs/ve38/lib/python3.8/site-packages/django/core/handlers/exception.py", line 34, in inner response = get_response(request) File "/home/my_user/.pyenv/versions/3.8.0/envs/ve38/lib/python3.8/site-packages/django/core/handlers/base.py", line 115, in _get_response response = self.process_exception_by_middleware(e, request) File "/home/my_user/.pyenv/versions/3.8.0/envs/ve38/lib/python3.8/site-packages/django/core/handlers/base.py", line 113, in _get_response response = wrapped_callback(request, *callback_args, **callback_kwargs) File "/home/my_user/.pyenv/versions/3.8.0/envs/ve38/lib/python3.8/site-packages/django/utils/decorators.py", line 130, in _wrapped_view response = view_func(request, *args, **kwargs) File "/home/my_user/.pyenv/versions/3.8.0/envs/ve38/lib/python3.8/site-packages/django/views/decorators/cache.py", line 44, in _wrapped_view_func response = view_func(request, *args, **kwargs) File "/home/my_user/.pyenv/versions/3.8.0/envs/ve38/lib/python3.8/site-packages/django/contrib/admin/sites.py", line 231, in inner return view(request, *args, **kwargs) File "/home/my_user/.pyenv/versions/3.8.0/envs/ve38/lib/python3.8/site-packages/reversion/admin.py", line 214, in revision_view return self._reversion_revisionform_view( File "/home/my_user/.pyenv/versions/3.8.0/envs/ve38/lib/python3.8/site-packages/reversion/admin.py", line 164, in _reversion_revisionform_view version.revision.revert(delete=True) File "/home/my_user/.pyenv/versions/3.8.0/envs/ve38/lib/python3.8/site-packages/reversion/models.py", line 101, in revert collector.collect(list(group)) File "/home/my_user/.pyenv/versions/3.8.0/envs/ve38/lib/python3.8/site-packages/django/db/models/deletion.py", line 245, in collect field.remote_field.on_delete(self, field, sub_objs, self.using) File "/home/my_user/.pyenv/versions/3.8.0/envs/ve38/lib/python3.8/site-packages/django/db/models/deletion.py", line 23, in PROTECT raise ProtectedError( django.db.models.deletion.ProtectedError: ("Cannot delete some instances of model 'my_other_model' because they are referenced through a protected foreign key: 'my_model.mylink'", <QuerySet [<my_model: my_model_string>]>) "GET /admin/my_app/organism/1/history/1/ HTTP/1.1" 500 121554

It would appear the offending part is when reversion tries to : "# Delete objects that are no longer in the current revision."

One questions, how can i access a many-to-many field queryset of a version?

This doesn't work, because it's not the data from the version, it's the current obj data:

obj = version.object_version.object
related = getattr(obj, field.name)
queryset = related.all()

the same with this:

concrete_model = obj._meta.concrete_model
many_to_many_fields = concrete_model._meta.many_to_many
for field in many_to_many_fields:
    queryset = field.value_from_object(obj)

One way i get the right data is this:

obj = version.object_version.object
related = getattr(obj, field.name)
ids = version.field_dict[field.name]
queryset = many_related_manager.filter(pk__in=ids)

Is this a best practise solution?

EDIT: Find out that the last example doesn't work, too: many_related_manager.all() will not return all existing values...

It's for: https://github.com/jedie/django-reversion-compare/commit/90b9c486aac170596568286bb5d37f73aefa09f1#L0R70

EDIT2: Some info of the objects in the example: version: instance of reversion.models.Version field: instance of django.db.models.fields.related.ManyToManyField and comes from: obj._meta.concrete_model._meta.many_to_many many_related_manager: instance of django.db.models.fields.related.ManyRelatedManager

I have created a "backup" functionality using the Django Reversion library for an object that keeps revision of a registered model, including the related objects (foreign keys etc.).

Let's use the following case as an example.

class Newspaper:
   title = models.CharField()

class Article:
   newspaper = models.ForeignKey('Newspaper') 

When the user clicks to keep a backup of a newspaper object, a revision of the newspaper is created along with the already created articles, under the same revision. I did it so that when the user chooses to revert back to the latest backup, all related objects under the same revision to be reverted.

The problem starts when a new article of the newspaper is created after the revision is created. The issue is that if the user chooses to revert to the previous revision (the one before creating the new article), the new article will still be there because it was not registered in the latest revision.

Furthermore, I don't want to create a new revision every time a new article is created because then there might be other changes included that the user will not want to include to the revision.

What I think might be a suitable solution, is when a new article is created, to create a Version of the article and register it in the latest created revision of the newspaper, but I don't know if it's possible using the functions provided by the API (maybe using add_to_revision?)

django-reversion needs IMHO a easy way to add a diff view. We only have this few helper methods, but no prepared way to add them to the Admin, see: https://github.com/etianen/django-reversion/wiki/Generating-Diffs

I started a new branch to add a simple diff view to VersionAdmin(), here: https://github.com/jedie/django-reversion/compare/diff

I made some screenshots (from 03.05.2012): http://www.pylucid.org/de/about/screenshorts/django-reversion/

The idea is to only add a generic diff and a developer can simply overwrite the method VersionAdmin.make_diff() to make a more meaningful diff.

The current make_diff() implementation makes a difflib.ndiff() over a "pretty-print" representation of the model data. IMHO this is the only reasonable thing to do in a generic way, isn't it?

Maybe we can remove make_diff() from the VersionAdmin class and insert the links to the diff view only, if the inherited Admin class implement a make_diff() method?

I have implemented a "backup" functionality when a user wants to keep a revision of his object along with all the related ones. I have implemented the admin integration and registered all the "follows" correctly. When the user presses the "create new backup" button, then the following code is executed:

    with reversion.create_revision():
        main_object.save()

        reversion.set_user(request.user)
        reversion.set_comment(comment)

and a revision is created for the object and all the related ones.

The problem appears when I create a new object that has a relationship to the main_object. When the new object is created, if the user presses "Create new Backup", then a revision is successfully created for the main_object and all the related ones BUT the previous revisions show this message on the admin panel: "Model instances without primary key value are unhashable".

The traceback that appears is:

File "/Users/platico/PycharmProjects/news-service/src/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response
  132.                     response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/Users/platico/PycharmProjects/news-service/src/lib/python2.7/site-packages/django/utils/decorators.py" in _wrapped_view
  110.                     response = view_func(request, *args, **kwargs)
File "/Users/platico/PycharmProjects/news-service/src/lib/python2.7/site-packages/django/views/decorators/cache.py" in _wrapped_view_func
  57.         response = view_func(request, *args, **kwargs)
File "/Users/platico/PycharmProjects/news-service/src/lib/python2.7/site-packages/django/contrib/admin/sites.py" in inner
  233.             return view(request, *args, **kwargs)
File "/Users/platico/PycharmProjects/news-service/src/lib/python2.7/site-packages/reversion/admin.py" in revision_view
  238.             context,
File "/Users/platico/PycharmProjects/news-service/src/lib/python2.7/site-packages/reversion/admin.py" in _reversion_revisionform_view
  184.                 version.revision.revert(delete=True)
File "/Users/platico/PycharmProjects/news-service/src/lib/python2.7/site-packages/reversion/models.py" in revert
  89.                         if item not in old_revision:
File "/Users/platico/PycharmProjects/news-service/src/lib/python2.7/site-packages/django/db/models/base.py" in __hash__
  521.             raise TypeError("Model instances without primary key value are unhashable")

with an Exception Type of TypeError and an Exception Value of Model instances without primary key value are unhashable

Hey, apologies if this is a known thing, but I've been unable to find an answer in the docco.

I'm trying to use fixtures to initialize some standing data for a Django Admin based application. Having loaded the fixtures, I call createinitialrevisions to initialize Reversion. The problem I'm having is that inline objects are being initialized with separate revision_ids to their parents in the reversion_version table (these are simple value objects, rather than being first class entities, and have no lifecycle outside their containing parent). I guess this makes sense as Reversion does not know which objects need to be versioned together. This means that if I amend or delete these parent objects, their dependent inline objects are not tied to the parents correctly, and cannot be reverted or recovered with them.

If I use the Admin GUI the relationship between the parents and inline objects is known, and Reversion can group the changes together correctly. However, for the initial bulk loading of data this isn't a practical approach.

Is there some way to tie data loaded through fixtures together so that Reversion knows what is going on when createinitialrevisions is called? If not, is there a recommended way to programmatically initialize related standing data in a Reversion friendly way?

Thanks for any pointers.

When reversion has been configured for the admin, the history view of an object shows the following:

The issue is that clicking on any of the linked versions immediately results in an attempt at reverting to that version. Regardless of any wording placed around the links, the linked pages are retrieved using HTTP GET and result in an "unsafe" operation, resulting in a violation of the HTTP spec:

If the purpose of such a resource is to perform an unsafe action, then the resource owner MUST disable or disallow that action when it is accessed using a safe request method.

Note use of the word MUST in the wording above (emphasis mine) - this is an absolute requirement and a strict violation of expected web semantics.

The fix seems relatively easy. Show an intermediary page (like Django does when deleting an object), asking the user to confirm their action which should then POST a request that performs the reversion returning a HTTP 301 response the Location header set to either the object history or change page.

Good evening,

The reason I'm interested in this pull request to be landed:

We frequently use model field from third-party library which can't be handled by core Django serializers.

I wrote custom serializer, not big deal. But now I need to mention custom format name in every call to register decorator.

Would be nice to set it once and forget about it :smile:

Best regards, Josiah.

The documentation notes:

Bulk actions, such as Queryset.update(), do not send signals, so won’t be noticed by django-reversion.

It would be helpful to expand that infobox with how people can work around that if desired and generate the versions anyway. In particular, I think looping over the queryset and using add_to_revision should work. Of course it would be good include a performance caveat, especially if #924 isn't fixed first.

Possible text:

Bulk actions (such as Queryset.update(), Queryset.bulk_update, or Queryset.bulk_create()) do not send signals, so won’t be noticed by django-reversion. You can use add_to_revision with bulk_update or bulk_create as a workaround, but this may eliminate the performance advantage of doing bulk actions since this requires fetching the objects into memory (unlike update()) and reversion will do one query per new version object (#924).

Between 1.8.0 and 1.8.6 (#380), reversion used bulk_create when creating versions, which presumably dramatically improved performance when creating a revision with many changed model instances[1]. It sounds like the motivation for removing this was inability to get back object primary keys from bulk_create, but that has since been fixed on some popular databases -- Django 1.10 (released about a year and a half after #380) added some support (only PostgreSQL at the time). SQLite was added in Django 4.0, and MariaDB was added sometime in the middle. It looks like there's a convenient feature test for this (connection.features.can_return_rows_from_bulk_insert), so it would be nice if django-reversion could use bulk_create when feasible.

(I found #380 while trying to figure out why tons of queries were being used despite the changelog claiming reversion uses bulk_create, so if you don't re-add bulk_create support it might be nice to note the change somewhere?)

[1] I haven't benchmarked this specifically, but a script that creates several thousand objects went from 30 minute runtime to ~3 minutes by doing far more query batching, so I suspect this is significant.