* better password hashing (bcrypt, etc...)
* time zone support
* built in selenium testing support
* bulk insert Models
* prefetch_related() (efficiently join m2m)
* SELECT FOR UPDATE support
* easy signing of cookies
* better project templates (basic scaffolding)
There are lots more... big release. Thanks to the all folks behind it.
It's really very simple: you just create a directory of files and point startproject/startapp to that directory with the --template flag. Files are copied over into the new app/project, with some simple replacements for things like the project name.
I've found using Jinja2 templates (http://jinja.pocoo.org/docs/ ) is a lot easier than dealing with the Django template language. Django also makes switching template languages quite easy.
It's a great release, but bulk_insert is really really dangerous because it apparently doesn't call the save() method nor the pre_save or post_save signals.
I don't like this because a lot of us put validation logic in Model#save and use the signals to trigger the search indexer, and so forth. This behavior is definitely going to catch some people off guard and it's bound to lead to serious bugs.
I understand why they don't call Model#save for every object, but I think they should have introduced something like Model#validate which is called before every save (including the new bulk inserts) so you still get a place to put custom validation logic that you know will get called the moment something is placed in the database. So now inserts are faster but at the expense of correctness. I'm not convinced that's a good trade off.
Oh, and for some reason bulk updates are completely missing, even though it seems natural to add bulk_insert and bulk_update at the same time.
This is the correct behavior, really. Bulk insert is not for cases where you have complex per-record validation or processing logic that also needs to be run in the application layer. It's for "I have all this data ready to go, now just shove it in there as efficiently as possible". If you need to have validation and additional per-record processing, signals, etc., insert the objects through the ORM normally. Yes, it'll be slower, but that's the price you pay for doing per-record processing.
To add to this, you could write your own validation method for a model and have your model's save method call this.
When processing bulk data sets you can iterate over calling your own validation then perform bulk insert knowing its validating. And your save will still validate as before.
The official website is more than enough, so long as you have python experience. If not, you should start with Dive Into Python (or something similar) at the same time at least.
If you have any MVC framework experience at all django is relatively straightforward.
Official docs are some of the best of any project (save maybe the best practices for view creation...).
I'd recommend skimming through a few Django applications to get an idea of structure, one I know off the top of my head (as I wrote it): https://github.com/zapier/django-knowledge
Django Book is ancient and obsolete as hell, but if you can fix most of the breakages, it is one of the best resources there are.
I don't agree that the documentation is great, but it is definitely good, although it is frustratingly lacking in some areas - although you won't run into that soon.
My suggestion is to try it in this order:
1. Django Book
2. Django Project Intro[1]
3. Django by Example[2]
The best tip to learning Django is to use #django on freenode[3]. People there will not do your work for you, but interactive live help is simply the best there is, unless you know forums like Something Awful where you can write out long-form questions to people who'll respond in the same fashion.
EDIT: I seriously wouldn't bother with any of the Django (book) books out there.
How's your Python? I hated Django when I was learning it and Python at the same time, but having abandoned Django (and sticking with plain old Python), when I revisited it a few years ago, things were dramatically easier.
In short, if your Python skills are passable, I'd say the docs at djangoproject.com[1] are more than sufficient. If not, I'd guess you might have troubles.
I got my initial exposure that way, but I had a hard time putting all the pieces together until I pulled Django out, and got a better understanding of which things came from where.
I should probably also point out that I'd only dealt with web languages before that point (PHP, ASP Classic, etc), so that's probably a negative point for me.
Everybody's different, for sure. For me, my Django suffered until I understood Python.
Can I ask what your pre-Django experience was? I wonder if there's any significance.
Maybe previous experience is significant - I learned to program building websites (HTML -> early CMSes -> PHP), then did a computer science degree (mostly Java, though I did a bit of Ruby on Rails), then got a job in C++ (where I still work, 3 years later), which I'd been doing for a year or so by the time I picked up Django.
To be honest, I suspect my Python's not great - I probably ought to spend more time just writing Python - I'd hazard a guess that less than 20% of the time I spend building websites with Django is spent writing Python (most is probably spent fiddling around with HTML/JS). I can always get by - but every once in a while I learn something new that I wish I'd known about long before (I remember learning about list comprehensions at an intro to Python talk at Stack Overflow DevDays after I'd been using Python for about a year!).
Since Railscasts.com is now making money through subscriptions, I'm surprised nobody's made a Djangocasts.com. Back when I was only flirting with web frameworks, Railscasts' bite-sized videos were the easiest way to get a taste of Rails.
For anybody interested in trying out the new templating system, this one has been active for a little while now and is based on the work of Mozilla and it has HTML5 boilterplate + Twitter bootstrap already, as well as Jinja2, Sphinx, Django-Admin-Panel, Markdown, Celery, South and some other niceties:
I actually prefer yours over the prior one. It seemed a bit too packed for me, yours is loose enough in structure and allows me to customize on a per project basis more easily.
Man, I just went through the 1.3 tutorial TWO days ago. Does anyone that uses Django know if the changes are huge? I guess I will be going through the 1.4 tutorial this afternoon.
How's SQLAlchemy working with MongoDB? I, for one, am very happy to be able to use MongoDB as a Django backend. I believe this is largely due to the fact that Django has never directly assumed data models to be stored in a SQL database, but has defined its own object abstraction layer instead.
I have a Django app in its early stages using 1.3, would it be a good idea to just transfer it over to 1.4? The only third-party app that it is using is django-registration...
The main problems I ran into when upgrading were with the new timezone support, but it was easy to just disable it (set `USE_TZ = False`) until I have a real need for the feature (and the time to fix the issues it causes for current code).
61 comments
[ 3.1 ms ] story [ 83.6 ms ] threadSome things to really dig:
There are lots more... big release. Thanks to the all folks behind it.http://amccloud.com/post/14689947527/django-1-4-custom-proje...
Does anybody have any reference to the scaffolding features? This might be the first I've heard of it.
Yeah, see https://docs.djangoproject.com/en/1.4/ref/django-admin/#djan... and https://docs.djangoproject.com/en/1.4/ref/django-admin/#djan....
It's really very simple: you just create a directory of files and point startproject/startapp to that directory with the --template flag. Files are copied over into the new app/project, with some simple replacements for things like the project name.
You can check out Django's source for the built-in one, or if you poke around on Github you'll find some others. Here's one, for example: https://github.com/amccloud/django-project-skel/.
I don't like this because a lot of us put validation logic in Model#save and use the signals to trigger the search indexer, and so forth. This behavior is definitely going to catch some people off guard and it's bound to lead to serious bugs.
I understand why they don't call Model#save for every object, but I think they should have introduced something like Model#validate which is called before every save (including the new bulk inserts) so you still get a place to put custom validation logic that you know will get called the moment something is placed in the database. So now inserts are faster but at the expense of correctness. I'm not convinced that's a good trade off.
Oh, and for some reason bulk updates are completely missing, even though it seems natural to add bulk_insert and bulk_update at the same time.
When processing bulk data sets you can iterate over calling your own validation then perform bulk insert knowing its validating. And your save will still validate as before.
https://docs.djangoproject.com/en/dev/topics/db/queries/#upd...
If you have any MVC framework experience at all django is relatively straightforward.
I'd recommend skimming through a few Django applications to get an idea of structure, one I know off the top of my head (as I wrote it): https://github.com/zapier/django-knowledge
Read the excellent Yipit Django blog (http://tech.yipit.com/). Especially their post about learning Django: http://tech.yipit.com/2012/02/28/183772464/
Introduction to Django http://pyvideo.org/video/604/introduction-to-django
and if you want to venture further down the rabbit hole
Django in Depth http://pyvideo.org/video/610/django-in-depth
I don't agree that the documentation is great, but it is definitely good, although it is frustratingly lacking in some areas - although you won't run into that soon.
My suggestion is to try it in this order:
1. Django Book
2. Django Project Intro[1]
3. Django by Example[2]
The best tip to learning Django is to use #django on freenode[3]. People there will not do your work for you, but interactive live help is simply the best there is, unless you know forums like Something Awful where you can write out long-form questions to people who'll respond in the same fashion.
EDIT: I seriously wouldn't bother with any of the Django (book) books out there.
[1]: https://docs.djangoproject.com/en/dev/intro/
[2]: http://lightbird.net/dbe/index.html
[3]: http://webchat.freenode.net/
In short, if your Python skills are passable, I'd say the docs at djangoproject.com[1] are more than sufficient. If not, I'd guess you might have troubles.
[1] - https://docs.djangoproject.com/en/1.4/
I should probably also point out that I'd only dealt with web languages before that point (PHP, ASP Classic, etc), so that's probably a negative point for me.
Everybody's different, for sure. For me, my Django suffered until I understood Python.
Can I ask what your pre-Django experience was? I wonder if there's any significance.
To be honest, I suspect my Python's not great - I probably ought to spend more time just writing Python - I'd hazard a guess that less than 20% of the time I spend building websites with Django is spent writing Python (most is probably spent fiddling around with HTML/JS). I can always get by - but every once in a while I learn something new that I wish I'd known about long before (I remember learning about list comprehensions at an intro to Python talk at Stack Overflow DevDays after I'd been using Python for about a year!).
Check it out: https://github.com/xenith/django-base-template
or just..
2. Run the test suite of the apps.
3. Run the apps with v1.4 and warnings turned on via:
Not only will you quickly see what's broken, but Django will dump helpful deprecation warnings for things that will eventually break at some point.I am glad sqlalchemy deals with sql-only databases.
You don't need an ORM for nosql. A library suffice.
Well, people don't need all the features all the time.
Else, they would use Oracle and not MongoDB.
In the same logic, they get by with Django ORM just fine.
As for the complexity, I don't think anyone ever called it complex...
[1] - https://github.com/dwaiter/django-bcrypt