Django 1.8 released

https://www.djangoproject.com/weblog/2015/apr/01/release-18-final/

by amarsahinovic • 11 years ago

286 52 11 years ago

djangoproject.com

JshWright• 11 years ago

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/

neokya2• 11 years ago

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

jsmeaton2• 11 years ago

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.

mslate• 11 years ago

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.

theli0nheart• 11 years ago

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.

alexhill3• 11 years ago

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.

whalesalad• 11 years ago

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...

jsmeaton2• 11 years ago

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.

shreyas0563• 11 years ago

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?

alexhill3• 11 years ago

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...

lukasm• 11 years ago

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

niix• 11 years ago

Build it :)

dguaraglia• 11 years ago

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

gonoobie• 11 years ago

Beego?

http://beego.me/

eeZi• 11 years ago

Well... Django predates Go by 7 years.

jzelinskie• 11 years ago

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

ElectricFeel• 11 years ago

What is Django? What does it do?

sdrothrock• 11 years ago

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/

tbatterii• 11 years ago

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

thecatspaw• 11 years ago

its a pretty popular web framework for python.

mmcclellan• 11 years ago

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.

zedpm• 11 years ago

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

jalonso510• 11 years ago

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.

bebop• 11 years ago

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.

crdoconnor3• 11 years ago

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.

kbaldor• 11 years ago

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.

ralmidani3• 11 years ago

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.

heyts• 11 years ago

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.

ralmidani3• 11 years ago

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.

misiti3780• 11 years ago

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

sanderjd• 11 years ago

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.

runjake• 11 years ago

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

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

chr15• 11 years ago

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/

ralmidani3• 11 years ago

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.

crdoconnor3• 11 years ago

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.

fallat• 11 years ago

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

lucianmarin• 11 years ago

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

bdr• 11 years ago

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

tomjen32• 11 years ago

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?

Xixi• 11 years ago

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.

danielsamuels• 11 years ago

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.

Django 1.8 released

Related Stories