Handling Changes in Model Definition

[pmargani]

Hi,
I've been using Reversion successfully for about a year, but recently
hit a snag. The definition of one of my Models has changed (a field
was removed), and now viewing the history does not work as before;
more specifically, deserializing the versions of this Model throws a
FieldDoesNotExist error.
So, is there support for handling changes to the Model definition in
Reversion?
Thanks
Paul

[David Hall]

Hi,

I get this question a lot! :P

The short, sad answer, is that Reversion relies on Django's model serialization framework, which doesn't allow models with missing fields to be deserialized. Until they add this feature, my hands are tied. (Well, I could write my own model serializer, but I don't really fancy that!).

If a model definition changes so that a new field is added, it should all just work. If a model definition changes so a field is removed, no dice.

I typically only use Reversion in it's admin capacity myself, so my approach has always been to let the website admin know, then selectively delete the Version models that will no longer deserialize.

It sucks, but this is a general feature of schema migrations. If you feel strongly about this issue, go poke the Django dev team to allow models to be deserialized in a way that ignores FieldDoesNotExist errors!

Anyway, sorry not to be any more help. I'm glad that Reversion has otherwise performed well for you!

Best,

Dave.

--
You received this message because you are subscribed to the Google Groups "Django Reversion Discussion" group.
To post to this group, send an email to django-r...@googlegroups.com.
To unsubscribe from this group, send email to django-reversi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-reversion?hl=en-GB.

--
Dave Hall
Etianen.com

Telephone: 07525 452381
Web: http://www.etianen.com

[pmargani]

Thanks a lot Dave!
That was the unwanted answer that I was expecting. Indeed, Reversion
has worked fine with additional fields, but doesn't like it when
fields are taken away.
Since I'm up the creek anyways, I was thinking of hacking the
Reversion tables in my database to remove the fields that no longer
exist. I suppose that would involve parsing the 'serialized_data'
text in the 'reversion_version' table, removing the field that no
longer exists, and (carefully) writing back. Apart from being a
horrible hack, do you see any problems with that?
Thanks again for this great package.
Paul

On Feb 11, 7:14 am, David Hall <da...@etianen.com> wrote:
> Hi,
>
> I get this question a lot! :P
>
> The short, sad answer, is that Reversion relies on Django's model
> serialization framework, which doesn't allow models with missing fields to
> be deserialized. Until they add this feature, my hands are tied. (Well, I
> could write my own model serializer, but I don't really fancy that!).
>
> If a model definition changes so that a new field is added, it should all
> just work. If a model definition changes so a field is removed, no dice.
>
> I typically only use Reversion in it's admin capacity myself, so my approach
> has always been to let the website admin know, then selectively delete the
> Version models that will no longer deserialize.
>
> It sucks, but this is a general feature of schema migrations. If you feel
> strongly about this issue, go poke the Django dev team to allow models to be
> deserialized in a way that ignores FieldDoesNotExist errors!
>
> Anyway, sorry not to be any more help. I'm glad that Reversion has otherwise
> performed well for you!
>
> Best,
>
> Dave.
>

[David Hall]

Hi Paul,

Nope, that sounds like a reasonable suggestion! Assuming you're using the JSON serialization format, it should be pretty easy to accomplish too. Not even sure if it qualifies as a hack. It's just modifying data, after all. Thats what programmers DO! :P

Good luck!

Dave.

[Andy Baker]

If django-reversion added a few utility functions for modifying
serialized data then it wouldn't be too hard to integrate with South
et al.

I'm thinking some functions to handle common cases like removing or
renaming a field.

Andy.

[David Hall]

Some commands to migrate version data might be a good idea. I guess the question is whether they would cover enough common use-cases to be worth including, and trying to make the syntax non-obscure.

Something like:

django-admin.py reversion_modify app_label model_name field_name [rename/remove] [new_name]

It's a bit long, though.

[Andy Baker]

On Fri, Feb 11, 2011 at 4:46 PM, David Hall <da...@etianen.com> wrote:
<snip>

>django-admin.py reversion_modify app_label model_name field_name
> [rename/remove] [new_name]
> It's a bit long, though.

1. In most cases you'd be running it in Python rather than via
manage.py as you'd probably be using something like South
2. You could have two commands rather than one dual-purpose one

So it might be more like:

from reversion.migrate import rename_field
rename_field('app', 'old_name', new_name)

[jar...@vortexrevolutions.com]

@David,

Has this been fixed in newer versions of Django / django-reversion? Your package is still one of the most actively maintained model versioning. I've recently inherited a project I'm trying to bring from 1.2 to 1.9 on Django ... I have about 24 libraries to contend with along that route.

Thanks,

Jarvis

[Dave Hall]

django-reversion is tolerant of schema migrations that delete fields and schema migrations that update fields without changing data type. Schema migrations that add new fields cause errors, however, and there's no real solution here.

Even if the django serialization framework supported it, applying a schema migration to GB of django model instances serialized as text would take a huge amount of time, rendering it useless.

Deleting invalid revisions remains the best approach here.

On the plus side, the admin interface should now give a nice error message instead of crashing out, so that's nice. :)

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 https://groups.google.com/group/django-reversion.
For more options, visit https://groups.google.com/d/optout.