- official Jinja2 support, and a generic template interface
- native postgres fields
- uuid field
and it is an LTS. Time to get upgrading.
This one is good.
I kind of wish it were default for primary keys, since the number of times I got burned by having databases I couldn't easily merge (which UUIDs help a lot with) way exceeds the number of times I had performance/memory issues caused by actually using UUIDs.
This, of course, assumes that temporally-adjacent additions are related, but this seems like a common case for large data sets since they often arise from a series of measurements or transactions.
I created this account to make this reply because I imagine that someone here is expert enough to set me straight if I'm mistaken.
When scanning the index, the database will be traversing it in btree order, anyway, so as long as the values are comparable, ints or UUIDs shouldn't matter much.
Performance shouldn't affect the decision to make it default, however. That would be premature optimization.
The only good reason I can think of for not making it default would be backwards compatibility.
HStoreField is going to be a significant improvement over the JSONFields we have been using...
However hstore has been a part of Postgres since version 8.2 released in 2006, and I think was around as a third-party project before that, so it's used by a lot of projects.
It's also easier to manipulate hstore values then json values within the database. hstore's simplicity allows operators for combining and subtracting hstore values which json doesn't have. Due to its restrictions, an hstore can also be converted to and from a record type (think database row). JSON fields on the other hand will generally be populated by your app and then only queried by the database.
However, the author of contrib.postgres opened this PR yesterday, so you can certainly expect them in the next release: https://github.com/django/django/pull/4427
The Django ORM has taken great strides lately. Another big improvement in 1.8 is the expansion of database expressions – you can now combine arbitrary database functions and columns as you can in SQLAlchemy. This is a big step towards a cleaner, logically consistent API, and makes extensibility (like that offered in the new contrib.postgres) much easier.
Django's ORM also does things that SQLAlchemy's doesn't. Even at its highest level SQLAlchemy requires explicit joins AFAIK.
That said the Django team is aware of SQLAlchemy's arguable superiority and there have been numerous proposals to integrate it somehow. The most likely plan would be to use SQLAlchemy core to replace the low-level SQL generation. That way you could take a Django queryset and get its SQLAlchemy representation, then continue building from there.
Alchemy has a lot more power behind it, but the Django ORM is (arguably) easier to use for the majority of web use cases.
I had a hand in opening up the Django ORM with the introduction/formalisation of Query Expressions (https://docs.djangoproject.com/en/1.8/releases/1.8/#query-ex...), and others are doing significant work in cleaning up the ORM internals so that more complex features can be layered on in core and by users.
1.9 will have support for jsonb, but you could always copy the above PR into your own project if you need that functionality.
I recently switched a project back to Django after some time playing with Rails.
One of the biggest attractions of Rails is the asset pipeline, but splitting the project and building the front-end with Ember-CLI takes away that advantage, leaving Django far ahead (IMO) with its cleaner ORM, less magical module importing, and Python's indented syntax.
I forgot to mention, part of the reason I went to Rails is its built-in support for building JSON APIs (at the time there was no clear winner among the Django API frameworks).
But now Django Rest Framework has matured quite well. By deriving everything from the model layer, it can help keep your API code nice and DRY.
The last LTR was Django 1.4 which will be supported until October 2015. The new LTR is Django 1.8 which will be supported until at least April 2018.
Django can move ahead and drop support for (honestly very outdated) Python versions like 2.5 and 2.6 so that newer Django releases can take advantage of additional features and nicer syntax in newer Python versions.
And companies stuck on python 2.6 because that's what's bundled in whatever version of RHEL can still get security patches to Django.
It's unreasonable to expect the (volunteer) django maintainers to indefinitely support every version of python or every version of Django.
And if you have no choice of upgrading to Django 1.5 yet, I'm sure you'd rather continue to get security patches until you can upgrade to 1.8.
Check out the models overview to get a feel for how powerful and simple it can be to use: https://docs.djangoproject.com/en/1.8/topics/db/models/
But half the time people use it as a MVC framework where URL's act as the final link back to the model.
Django makes it easier to build better Web apps more quickly and with less code.
There are plenty of large sites using django
"the more simplistic 'Python' language"
"a real language like Ruby or Pearl"
Plus there's the typo:
*Pearl -> Perl
Python is quite real, my friend. No need to dis.