Jeff Croft

I’m a digital product designer and developer in Seattle, WA. I currently work with nGen Works, and recently co-founded Lendle, a Kindle book sharing service.

Some of my clients include Facebook, Microsoft, Yahoo!, Copious, The New York Review of Books, The Lawrence Journal-World, and the University of Washington.

I’ve authored two books on web and interactive design and spoken at dozens of conferences around the world.

Link // 10.11.2008 // 3:15 PM // 4 Comments

django-reversion

Another approach to version controlling the content in your Django database. This one looks remarkably good, at a glance. It stores revisions in the database, rather than an external version control system, and can be added to an existing project with just a few lines of code (and no modifications to your existing models). Looks very slick. I only have one question: what happens when you make a schema change to a versioned model (i.e. add/change/delete a field)? I’m going to assume this would render the versioned content unusable, but I’m not sure about that. Anyone know?

Visit site...

Comments

  1. 001 // sampablokuper // 03.10.2009 // 1:21 PM

    Hi Jeff,

    Have you found the answer to your question about django-reversion? I ask because I’d like to know the answer too!

    Thanks,

    Sam

  2. 002 // nike air yeezy // 05.20.2009 // 2:22 PM

    thanks

  3. 003 // Monika // 08.11.2009 // 6:17 AM

    I tested it out a little bit and it looks like adding fields or changing field types and field options is not a problem. Deleting fields, however, is problematic (I get a FieldDoesNotExist Exception in the admin).

  4. 004 // Dave Hall // 01.28.2010 // 7:16 AM

    Hi,

    I wrote and maintain django-reversion, so hopefully I can shed some light…

    As it stands at the moment, django-reversion is completely ignorant of the idea that models may change over the lifetime of an application. The reason behind this is simplicity, and keeping the codebase small. My current thinking is, if you alter the model, the version history becomes less useful anyway, and can just be discarded.

    As has been pointed out above, adding fields to the model does not actually cause a problem, and you can also change fields so long as the string representation of the field can still be parsed by the new field. Thus, at the moment, so long as you don’t delete fields on the your model, it will all Still Work.

    The obvious thing to do would be to make the system also tolerant of deleted model fields. However, in this regard I am at the mercy of the django serialization framework. If the django team could be persuaded to make their serialization framework tolerant of missing fields, then django-reversion would become likewise tolerant.

    I could, of course, write some complex hack to just make it all work, but that wouldn’t be pretty at all. :)

    No worries,

    Dave.

Tags for this link