"incompatible version data" -> migrate versions JSON, too ?

[jedie]

Now and then a user may see the error:

reversion.errors.RevertError: Could not load <Foo: bar> - incompatible version data.

e.g.:

• Error resulting from change of schema?  #739
• Calling field_dict fails when serialized_data contains BooleanField which is null #645
• incompatible version data for each models.DateField #613

First thing to do is IMHO:

1. Add a clear note about the problem in the documentation. -> docs: Add "incompatible version data" in "common problems" #860
2. Enhance the error message, so the user knows what happend

On the long run:

Why not hacked into Django migration system and "migrate" the saved JSON data, too?
It is probably not easy. But it should be possible in theory, isn't it?

[etianen]

Revision databases are often far too large to migrate in any reasonable timeframe, and hacking into the Django migration system is likely to be very difficult and fragile. I'm not sure it's possible, or even desireable, to do so.

…

On Wed, 24 Feb 2021 at 07:53, Jens Diemer ***@***.***> wrote: Now and then a user may see the error: reversion.errors.RevertError: Could not load <Foo: bar> - incompatible version data. e.g.: - #739 <#739> - #645 <#645> - #613 <#613> First thing to do is IMHO: 1. Add a clear note about the problem in the documentation. 2. Enhance the error message, so the user knows what happend On the long run: Why not hacked into Django migration system and "migrate" the saved JSON data, too? It is probably not easy. But it should be possible in theory, isn't it? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#859>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABEKCCJ2STB6JEDJJN2CL3TASWBDANCNFSM4YEAI6TQ> .

[jedie]

Yes, you may be right, it won't be easy in any case.

A work-a-round that works without migration might be something like that:

• Load the current model.
• Change the values field by field from the history. Maybe call clean() after each change. Skip fields that can be assigned or raise a ValidationError

But this is not a really nice solution. But at least better than just to crash ;)

[etianen]

That would require parsing all the different serialization formats Django offers. I don't see a way of getting the deserialized field values using their API. https://docs.djangoproject.com/en/3.1/topics/serialization/ Really, to support this better, Django-reversion would have to standardize on a serialization format, such as JSON. To support it in any performant manner though, we'd really want to use a database table per model approach, so that migrations can be applied to the version data using the Django migrations framework. Either approach would effectively be a rewrite of Django reversion though, with no clear migration path for existing users.

…

On Wed, 24 Feb 2021 at 14:39, Jens Diemer ***@***.***> wrote: Yes, you may be right, it won't be easy in any case. A work-a-round that works without migration might be something like that: - Load the current model. - Change the values field by field from the history. Maybe call clean() after each change. Skip fields that can be assigned or raise a ValidationError But this is not a really nice solution. But at least better than just to crash ;) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#859 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABEKCBPNT47LI5PA2HER3LTAUFS3ANCNFSM4YEAI6TQ> .