Posts Tagged ‘django’

Upgrading django

December 28, 2007

I just upgraded my website to the development version of django. It has a bunch of new little features I’d like to use; and the next time I change the database I want to try django-evolution, which doesn’t work on 0.96.

It was easier than I had feared. For the website itself, I didn’t run into anything unexpected, just these, all documented:

  • In all the models I changed __str__ to __unicode__; that was a simple substitution.
  • Also in all the models’ fields maxlength went to max_length.
  • I had to add a call to smart_string to my csv view.
  • I’ve found one place I that needed protection from html escaping. The problem was a string containing   in a python file; I wrapped it with mark_safe there, rather than adding a more general but less safe fix to the tag that eventually uses it.

I have a couple of utility scripts that were more of a problem. One needed to be rewritten because of the massive changes to django’s core.management module; the new version is a bit cleaner than the old, so that pleases me. The other is a problem with json serialization, which (at least as I’m (mis?)using it) now seems to have trouble with non-ascii unicode strings. But that I don’t really need (and if I did, xml seems to work fine), so figuring it out isn’t a high priority.

The big change here was obviously unicode. I see the advantage of that in the abstract, but I do have to wonder if it is really a win in my particular case. I have non-ascii (and non-latin1) data, but utf8-encoded strings worked just fine for me. Probably though that’s a reflection of the triviality of the text-processing I do…

UPDATE: Just found another gotcha: urllib.quote doesn’t like non-ascii unicode. Fixed with smart_str.

UPDATE 2: I should RTFM; the correct fix for the first update is to use django’s own url functions. Also, I forgot to mention one thing I had to do originally: fix a typo in a template! 0.96 let this get by:

	{% extends "foo.html" }

Some django stuff

December 26, 2007

I generally love Django, but it does have some real holes. The worst problem for me is its complete lack of support for database changes. The Django devolppers argue, maybe convincingly, that database evolution is delicate enough that it’s dangerous to automate. But I feel like it’s dangerous enough it shouldn’t all be left to me either. I’m not particularly scared of SQL per se, but I know I could easily get something wrong. Do Rails’ schema evolution things make that easier, or at least less scary?

I just added “created” and “modified” date fields to one of my models, both using Django’s automated date fields, that set themselves to the current date when an object is added/modified. That led to an extra complication: I wanted the real dates for all my already-existing data. Fortunately Django’s admin keeps a log from which all the modification dates can be extracted. Once gotten, they can’t be saved to the database through Django’s normal model inerface–as that would be a modification that would auto-set the modification date, exactly what I don’t want to do.  So that required a bit more SQL.

OK, despite my whingeing the SQL for that was pretty trivial.  I’ll suck it up now. The interesting bit was the python function for extracting dates from logs:

 

def getdate(obj, addition):
    """
    Look at the logs to find creation/modfication dates.
    """
    model = type(obj)
    # we need the contenttype
    ct = ContentType.objects.get_for_model(model)
    # now we can look up the logs for this object
    logs = LogEntry.objects.filter(content_type=ct,
            object_id=obj.id).order_by('-action_time')
    dates = [l.action_time.date() for l in logs \
                if not addition or l.is_addition() ]
    try:
        return dates[0]
    except IndexError:
        return None