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
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.
On 11 February 2011 11:17, pmargani <pmarg...@nrao.edu> wrote:
> 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
> -- > 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-reversion@googlegroups.com. > To unsubscribe from this group, send email to > django-reversion+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-reversion?hl=en-GB.
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:
> 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.
> On 11 February 2011 11:17, pmargani <pmarg...@nrao.edu> wrote:
> > 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
> > --
> > 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-reversion@googlegroups.com.
> > To unsubscribe from this group, send email to
> > django-reversion+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/django-reversion?hl=en-GB.
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.
On 11 February 2011 12:52, pmargani <pmarg...@nrao.edu> wrote:
> 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.
> > On 11 February 2011 11:17, pmargani <pmarg...@nrao.edu> wrote:
> > > 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
> > > -- > > > 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-reversion@googlegroups.com. > > > To unsubscribe from this group, send email to > > > django-reversion+unsubscribe@googlegroups.com. > > > For more options, visit this group at > > >http://groups.google.com/group/django-reversion?hl=en-GB.
> -- > 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-reversion@googlegroups.com. > To unsubscribe from this group, send email to > django-reversion+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-reversion?hl=en-GB.
On Fri, Feb 11, 2011 at 12:54 PM, David Hall <da...@etianen.com> wrote: > 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.
> On 11 February 2011 12:52, pmargani <pmarg...@nrao.edu> wrote:
>> 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.
>> > On 11 February 2011 11:17, pmargani <pmarg...@nrao.edu> wrote:
>> > > 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
>> > > -- >> > > 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-reversion@googlegroups.com. >> > > To unsubscribe from this group, send email to >> > > django-reversion+unsubscribe@googlegroups.com. >> > > For more options, visit this group at >> > >http://groups.google.com/group/django-reversion?hl=en-GB.
>> -- >> 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-reversion@googlegroups.com. >> To unsubscribe from this group, send email to >> django-reversion+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/django-reversion?hl=en-GB.
> -- > 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-reversion@googlegroups.com. > To unsubscribe from this group, send email to > django-reversion+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-reversion?hl=en-GB.
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.
> 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.
> On Fri, Feb 11, 2011 at 12:54 PM, David Hall <da...@etianen.com> wrote: > > 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.
> > On 11 February 2011 12:52, pmargani <pmarg...@nrao.edu> wrote:
> >> 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.
> >> > On 11 February 2011 11:17, pmargani <pmarg...@nrao.edu> wrote:
> >> > > 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
> >> > > -- > >> > > 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-reversion@googlegroups.com. > >> > > To unsubscribe from this group, send email to > >> > > django-reversion+unsubscribe@googlegroups.com. > >> > > For more options, visit this group at > >> > >http://groups.google.com/group/django-reversion?hl=en-GB.
> >> -- > >> 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-reversion@googlegroups.com. > >> To unsubscribe from this group, send email to > >> django-reversion+unsubscribe@googlegroups.com. > >> For more options, visit this group at > >> http://groups.google.com/group/django-reversion?hl=en-GB.
> > -- > > 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-reversion@googlegroups.com. > > To unsubscribe from this group, send email to > > django-reversion+unsubscribe@googlegroups.com. > > For more options, visit this group at > > http://groups.google.com/group/django-reversion?hl=en-GB.
> -- > 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-reversion@googlegroups.com. > To unsubscribe from this group, send email to > django-reversion+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-reversion?hl=en-GB.
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)
