While you’re able to customize the error message for a unique field when defining your model…
…you can’t do the same for a unique_together constraint. There’s an open ticket but it hasn’t seen much attention. In the meantime, you can override the unique_error_message in your model to provide a custom error message:
By default instance.save() flushes all fields to the database. While this can be handy in some use cases, more often than not you only need to save a subset of fields. Folks have resorted to various workarounds to deal with this behavior, none of which are very pretty.
Luckily Django 1.5 remedies this situation with the new update_fields argument for save(). This not only gives you a minor performance boost, but can also help with certain race conditions.
One thing to note if you use deferred model loading:
“When saving a model fetched through deferred model loading (only() or defer()) only the fields loaded from the DB will get updated. In effect there is an automatic update_fields in this case. If you assign or change any deferred field value, the field will be added to the updated fields.”
It’s often necessary to get access to the request object from within a ModelForm. To do this, you’ll need to override a single method in both the ModelForm and FormView.
First the FormView:
And now the ModelForm:
As promised in my first post, I’m going to be looking at the reasons I chose to go with Django rather than Symfony2. Aside from wanting to learn a new language, there were a few things that jumped out at me when looking into Django.
One of the biggest was the dramatic amount of code necessary to do the same thing in Symfony2. Let’s look at a typical model for a blog. Here’s what it looks like in Django (I’ve added a small utility function via a manager):
models/blog.py
Now here’s the same model in Symfony2 along with the utility function:
Entity/Blog.php
Entity/BlogRepository.php
Wow, that’s a TON of code. I will mention that Symfony2 does offer some tools to help generate this code, which are very helpful. But it feels to me like they’re trying to overcome the shortcomings of the language.
Let’s say you have a field defined as the following in your model:
You can then use the max_length in your ModelForm like this:
One of the first things I noticed when I started with Django was that models and views were single files. Now I’ve read various opinions on how things should be handled (multiple modules vs. multiple files) but I’m of the opinion that clarity is always better. So even if you have a single model, I’d rather have the file be named something descriptive rather than the generic models.py.
Breaking things up into multiple files is quite straight-forward – delete models.py, create a models directory, add __init__.py and create your model classes. Here’s an example:
__init__.py
Note: In order for syncdb to see your models and work correctly, you’ll need to import the models in __init__.py.
models/blog.py
Note: The Meta class is necessary for Django to associate the model correctly. Just set it to the name of your application. Otherwise syncdb won’t see your models or you’ll get a lovely error like the following when one of your models contains a foreign key:
You can then import your models like this:
