Django 1.8 released | Hacker News Reader

Django 1.8 released

djangoproject.com

286 pointsamarsahinovic57 comments

Open articleView on HN

Some great things in this release:

- official Jinja2 support, and a generic template interface

- native postgres fields

- uuid field

and it is an LTS. Time to get upgrading.

>uuid field

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.

Databases aren't my field, but I would expect this to hurt performance by decreasing locality of keys.

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.

Postgres at least will store rows roughly in insert order. So whether you're using integers or UUIDs for primary keys won't affect on-disk layout.

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.

It might negatively affect performance, yes.

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.

I'm especially excited about contrib.postgres[1].

HStoreField is going to be a significant improvement over the JSONFields we have been using...

[1] https://docs.djangoproject.com/en/1.8/ref/contrib/postgres/

Yea, this. I am starting all new projects with Postgres because of this official support. Kudos to the team :)

Also - https://github.com/django/django/pull/4427

1.9 will have support for jsonb, but you could always copy the above PR into your own project if you need that functionality.

Thanks for link. Will keep eye on it :)

It humors and saddens me that Django is a web framework with an ORM bolted on. SQLAlchemy has had a postgres driver that supports HSTORE and JSON/JSONB for ages.

Why does it sadden you? It seems like the majority of use-cases for database interaction (at least with the relational ones, likes PostgreSQL or MySQL) occur in web frameworks. The coupling makes a lot of sense to me, especially given the opinionated nature of programming in Python.

Likewise, Django has had third-party hstore and jsonb fields for ages, but I take your point. SQLAlchemy is beautiful.

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.

SQLAlchemy is awesome, but it's an order of magnitude more complex to setup and configure than the Django ORM. With Django you get the integration with migrations, a system to spin up and tear down test databases, less boilerplate code required during model configuration (like not needing to specify the name of the database table), etc...

From the quick searching I've done, I think that Django predates SQLAlchemy by nearly a year (July 2005 and May 2006 respectively).

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.

Please help me understand this better. So HStoreField is not exactly Json field type of postgres but rather a subset of it, i.e just string->string mapping without any nesting. You cant even have key->array mapping?

Basically yes. hstore and json have entirely separate interfaces in Postgres, but the storage properties of hstore are a subset of json as you say. json/jsonb is generally more powerful, and will supplant hstore in a lot of new projects.

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[0] 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.

[0] http://www.postgresql.org/docs/9.4/static/hstore.html#HSTORE...

Thanks for the explanation. So this means that Django does not support JSON or JSONB field types yet

Not built-in, but there are plenty of third-party JSON fields around.

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

Great! this is very helpful

Really like that they added a way to store time intervals as python timedelta objects. Previously i think the best approach was to store a number of seconds as an integer and then calculate the number of minutes, hours etc.. yourself.

Great work, Django team!

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'm genuinely curious, have you tried one of the asset-pipeline apps for django? I found django-pipeline actually not that bad, even though I have been recently leaning towards using front-end tools (gulp/browserify) anyway.

I have not. For the front-end I'm using Ember, and Ember-CLI takes care of Emblem templates, Sass, and CoffeeScript, plus breaking code up into ES6 modules. Eventually they plan to require using it in order to get all of the features of Ember.

I was using Jammit (ruby) for assets but recently switch the django-pipeline and it is working well. For front end apps, I use Grunt.js because I am to lazy to upgrade to something new

I'd love to hear about your experiences with building APIs for single-page-apps between Rails and Django. Were you using rails-api or just straight-up Rails? Is there an equivalent API-focused "flavor" of Django, or if not, to what extent did you find it easy to choose not to use server-rendering functionality? I've used Django for more standard apps, and Rails for both, but I'm curious about the pros and cons of using Django for this sort of thing, because I have no experience with it.

> Is there an equivalent API-focused "flavor" of Django?

http://www.django-rest-framework.org/

Django REST Framework is the the most popular way to build APIs with Django. Lot of neat features out of the box such as throttling and permissions make it easy to build API endpoints.

http://www.django-rest-framework.org/

I'm still new to building APIs with Django. Last time I was immersed in Django, I was focused on server-side rendering.

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.

Have you used django-pipeline? It's damned good. I wouldn't start a new project without it. Almost wish it was part of core.

This is why I stopped using Rails too. It was just too magical. I hate magic I can't understand.

I really wish there was something as mature as Django in Go (A little bit lightweight maybe)

Build it :)

Wouldn't a new framework be the opposite of the 'mature' framework s/he wishes existed? :)

On the other hand, Django was a new framework, once. If you want to create a web framework for Go that is equivalent to Django, you have to start somewhere.

Beego?

http://beego.me/

Well... Django predates Go by 7 years.

revel[0] is probably the best there is right now -- it's probably more similar to Play! of Scala/Java fame.

[0]: https://github.com/revel/revel

Thanks to the Django team for a incredibly well-run and well-documented OS project!

Damn Django is pretty hard at sunsetting old versions. If they are going to release a new one in October and only supply security upgrades to things that are two versions behind, does that means you have to upgrade your system in less than a year?

Django has long term releases if you wish to upgrade less often.

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.

And Django 1.4 was released on the 23rd of March 2012, so if you stick with the LTS releases you very rarely have to upgrade. I have to say though, I wouldn't want to upgrade a 1.4 app to 1.8 - lots of big changes have happened between those two releases.

Agree. The LTS releases are great, but for anything you expect to be working with on an ongoing basis I think it's worth the yearly pain of upgrading rather than a huge headache every three years.

It is just that I imagine most IT projects have a timespan in decades so ideally you want something like Java that can still run your old stuff and where upgrading means putting out a new runtime.

The reason for the LTS versions is in large part for enterprises that are stuck on older versions of Python because of RedHat support contracts and the like.

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.

What is Django? What does it do?

It's a MVC (Model-View-Controller) web framework made in Python that works with a number of different kinds of databases.

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/

Actually a MTV framework https://docs.djangoproject.com/en/1.8/faq/general/#django-ap...

Strictly speaking it's a MTV framework (like all traditional web frameworks really).

But half the time people use it as a MVC framework where URL's act as the final link back to the model.

its a pretty popular web framework for python.

Fine, I'll see your negative karma and raise you the heading from the site:

Django makes it easier to build better Web apps more quickly and with less code.

You either see (call) a bet or you raise it, you don't see and raise, as it's confusing. There's a name for this confusing, inappropriate behavior in a poker game: string bet [0], and it's simply not allowed at most tables.

[0] http://www.pokertips.org/glossary/w/STRING+BET

Can’t wait to update https://sublevel.net to this version!

Reply on news.ycombinator.com