12 ms·

Django 1.11 beta 1 released

167 points by tweakz 10y ago

mozumder 10y ago
Subquery expressions looks like it would be just easier to write SQL, instead of going through the Django ORM. This is where SQL starts to show its expressive strength over ORMs.
- jsmeaton 10y ago
  You're right, except for when you need to support multiple database backends. For projects it's usually not a concern, but for libraries it certainly is. The ORM has been slowly adding more and more complex types (Expressions) for more complex use cases, which can be mostly ignored for regular CRUD apps.
  - mozumder 10y ago
    Aren't SQL subqueries pretty much standard across all databases anyways? Why would writing them in Django's ORM be more compatible?
    - jsmeaton 10y ago
      Field names, table names, quotes or not - a few examples of things that can differ. The syntax of subqueries themselves are standard AFAIK. Building subqueries inside Django gives the rest of Django access to them for things like aggregation or filters.
- Alex3917 10y ago
  If you already know SQL but don't know any Django, then yes. But if you already know all the other Django model functionality and it's just a matter of learning the new Subquery syntax, then it's probably easier to do in the ORM. There is definitely a benefit to querying everything the same way if you can, so that way it's easy to grep where different tables are being accessed. Cuts down on bugs, security issues, etc.
- Waterluvian 10y ago
  Absolutely. The amount of "magic" Django does slowly became a real detractor for me. The way I define queries by using a custom language in the form of keyword arguments makes me wonder why I don't just learn SQL instead? I would much rather do something like: models.Foo.objects.filter(sql=my_sql_query_str) Instead of something like: models.Foo.objects.filter(name='bar', parent__siblings__count__lt=3) And no special abstraction on SQL in the form of special classes. Just a string of SQL that I compose with Python string formatting. SQL isn't scary. I don't see the need to try and hide it.
  - metaphorm 10y ago
    https://docs.djangoproject.com/en/1.10/topics/db/sql/#django.db.models.Manager.raw https://docs.djangoproject.com/en/1.10/topics/db/sql/#django... you can already do this. the django ORM has a convenient and expressive API for a lot of very common types of queries, but lets you easily drop back into raw SQL when you have a high complexity query that you want to write by hand.
    - jsmeaton 10y ago
      Raw requires a primary key to be returned so it can rebuild the model object for you. You could also use django.db.connection.cursor() directly.
  - Alex3917 10y ago
    > Where I assemble a SQL query string using string formatting and vanilla Python. You can just add various filter conditions to a dictionary, and then unpack them into the filter as kwargs. That way you can still build up the dictionary using if/else blocks or however you would normally build up a SQL query string. SQL isn't scary, but for simple queries the Django ORM usually a lot more legible if you take the time to learn the DSL.
  - symlinkk 10y ago
    > Just a string of SQL that I compose with Python string formatting sounds like an SQL injection waiting to happen
- ksri 10y ago
  Take a look at JinjaSQL - https://github.com/hashedin/jinjasql https://github.com/hashedin/jinjasql. Beyond a certain complexity, Django ORM gets in the way. Constructing SQL by hand is painful and can lead to SQL injection. And that's where JinjaSQL shines. You write your query as a string template, and then jinjasql interpolates the variables and provides the bind parameters. Makes it easy to maintain complex queries.
  - bradmwalker 10y ago
    http://docs.sqlalchemy.org/en/latest/core/ http://docs.sqlalchemy.org/en/latest/core/
- andybak 10y ago
  I learnt SQL before learning any ORM but the Django ORM just 'fits my brain' better. Especially when you factor in the fact that it handles 90% of common cases with a very simple syntax. In fact - due to lazy evaluation you can combine simple ORM queries and quite often you end up with subqueries behind the scenes. The Aggregate/Annotate syntax is a wonderful thing and I often find myself surprised writing queries that have some of that "Just Do What I Mean" magic. Admittedly I rarely have to deal with the need for highly performant database code. But one could argue that performance problems are often better handled via caching or denormalisation (which really boil down to the same thing) than by clever work on the db side.
  - brianwawok 10y ago
    It is my favorite ORM out there. Maybe a little too easy to do accidental joins, but you can do that in SQL too.
- danpalmer 10y ago
  I'm not sure I agree. For crossing the boundary from the database to Python objects, I think the ORM is far more expressive than SQL. Sure the query might not be as nice, but the query is only half of the process, there's all the serialisation/deserialisation, injection protection, assignment to Python objects, possible lazy query interfaces, etc.
jitl 10y ago
Release notes with the new features in 1.11: https://docs.djangoproject.com/en/dev/releases/1.11/ https://docs.djangoproject.com/en/dev/releases/1.11/ Highlights: - better support for creating indexes on your Models with class-based indexes - widget rendering in forms now uses the templating system instead of python - Explicit subquery expression support via Subquery and Exists expressions.
- jsmeaton 10y ago
  Some more important notes (IMO): - Long Term Support - Last release to support Python 2 - Server side cursors for postgres
- aptwebapps 10y ago
  widget rendering in forms now uses the templating system instead of python I haven't looked at how it's implemented yet, but that sounds like a real godsend.
  - collinmanderson 10y ago
    There's now a get_context() method which returns a dict of useful info. the render() method takes that and applies it to widget.template_name.
  - legostormtroopr 10y ago
    I have looked at it, and it is a godsend.
  - Buetol 10y ago
    They did the same with the login views, they are now class-based and easy to customize. Very useful when you have an exotic templating engine for example and can't inherit the `registration/login.html` template
- collinmanderson 10y ago
  > The cached template loader is now enabled if DEBUG is False This should give a decent performance improvement for many websites.
bedros 10y ago
my favorite feature so far is search, this is first LTS release with search support builtin (was introduced in 1.10) https://docs.djangoproject.com/en/1.10/ref/contrib/postgres/search/ https://docs.djangoproject.com/en/1.10/ref/contrib/postgres/...
- wjdp 10y ago
  Rather looking forward to this. Got a number of use cases that don't justify using a 'proper' search engine but would really benefit from a more flexible search than an icontains filter.
  - legostormtroopr 10y ago
    Have you had a look at Whoosh and Haystack? Whoosh is pure python and Haystack is a nice Django-like wrapper around search engines. * whoosh.readthedocs.io * haystacksearch.org
pmulv 10y ago
This is a bit off topic, but can anyone suggest a decent Django tutorial? I've just recently learned python, and would like to build a few projects using Django. I completed Django's official tutorial[1], but when it came time for me to actually start building something, I found I didn't really understand what was going on. I should mention I'm inexperienced in both web application development and python in general. 1: https://docs.djangoproject.com/en/1.10/intro/tutorial01/ https://docs.djangoproject.com/en/1.10/intro/tutorial01/
- phodo 10y ago
  A bit of googling and you will find many excellent resources - filter on 'last year' in the search results. One recommended book is 'two scoops of Django'. You should get familiar with the request response cycle (Language agnostic) and that will make things a lot clearer as you build up your skills.
  - pen2l 10y ago
    Two scoops is an okay book I suppose, but it's definitely not what the grandparent post is asking for -- it goes over things too quickly. I actually recommend youtube video tutorials! Like, some will show you how to make a basic photo hosting site... a blog site, etc. Follow those once or twice, and take it from there. Best of luck!
- dtran 10y ago
  I highly recommend Two Scoops of Django and have recommended to every engineer at my company. The one caveat would be that the newest edition is for Django 1.8, so it'd be good to check against the docs periodically if anything looks off. Off the top of my head, the main thing I'd keep an eye out for would be changes to Class-Based Views like permissions mixins, although if I remember correctly, most of those changes were just moving things in django-braces to Django core.
  - legostormtroopr 10y ago
    Danny and Audrey are busy updating two-scoops for version 1.11, so if you can hold off on buying, do so, simply because 1.11 will be the next LTS release.
yeukhon 10y ago
> The Django 1.11.x series is the last to support Python 2. The next major release, Django 2.0, will only support Python 3.5+. Really the most important part of this release, out of all. This is the time where enterprise companies using Python and Django really need to switch to Python 3. In fact, anyone using Ubuntu 16.04 should already find themselves going "ugh" because they needed Python 2. More reasons to push forward.
- ProblemFactory 10y ago
  I like the model of https://railslts.com/ https://railslts.com/ It's reasonable that volunteer developers working on an open-source project sunset old versions, and old versions of language runtimes or dependencies. Nobody wants to keep maintaining 5-year-old versions with 12-year-old dependencies when they could use their time to improve the latest version instead. Django is one of the most "responsible" projects in this regard - having LTS releases that are maintained for three years for free. Some projects even say "you should stick with github master" for fixes :) But it's cool that Rails has a company providing paid enterprise support after the community support ends. Their pricing is surprisingly cheap - I would expect that if an enterprise has a legacy application that must be kept "stable" and never upgraded, then they would be willing to pay $10k and upwards per month for that privilege.
  - collinmanderson 10y ago
    Yes, very likely 1.11 will end up getting unofficial community support after 2020. Django 1.6 (the last version to support Python 2.6) is still getting unofficial support: https://github.com/beanbaginc/django https://github.com/beanbaginc/django
  - jsmeaton 10y ago
    I'd be very surprised if there wouldn't be a market for unofficial support of older Django versions - especially 1.8 or 1.11 in the future. It wouldn't be a 'sexy' company, but it'd make money and please a lot of big businesses.
vosper 10y ago
I've been building a project with Django Rest Framework (DRF), it's my first time using anything Django-related. Does anyone know whether new versions of Django tend to drop right into DRF, or whether DRF has to do some work to be compatible with a new version? I ask because I like the sound of the fulltext search mentioned in another comment, because it would mean I don't have to install a search engine to support that feature. So I'd switch to Postgres and start using Beta 1 pretty soon, if DRF will just-work with it.
- oliwarner 10y ago
  I really don't mean this in as aggressive a way as it might read without this prefix but... Why don't you just try it?
  - vosper 10y ago
    I guess I could try grabbing the beta with pip, and I suppose there's probably some test suite for DRF that I could find and run. The thing I don't know for sure is that if the test suite passes then I'm good to go.
    - StavrosK 10y ago
      Things generally tend to break loudly, so if your test suite (for your app) passes, you should be good to go.
- orf 10y ago
  Yes, they generally work really well. You could give it a spin and report any issues you may find in the alpha to the DRF team :)
- pythonaut_16 10y ago
  I would try it in development, run your tests, etc. But wait to deploy anything to production until DRF officially supports it (which should be pretty much at launch, DRF should be working with the beta now to ensure compatibility)
- 10y ago
jbub 10y ago
Class based indexes - looks great, is there support for CREATE INDEX CONCURRENTLY for postgres ?
- rowanseymour 10y ago
  I also wondered that but seems from https://code.djangoproject.com/ticket/21039 https://code.djangoproject.com/ticket/21039 they'd prefer devs to do that manually in migrations marked as non-atomic
  - brianwawok 10y ago
    Makes sense, would be weird to start testing while indexes are building
    - rowanseymour 10y ago
      CONCURRENTLY doesn't build indexes asynchronously - it just builds them in a way that doesn't lock the table.
      - brianwawok 10y ago
        Oh I thought it returned control after you hit it.
omegote 10y ago
The new way of rendering form widgets is something I've been waiting for a long time. Now using custom form widgets like those in Bootstrap, or more complex fields like datepickers and the like should be as easy as dropping the HTML templates for those widgets in the proper folder, which is great.

167 points by tweakz 10y ago

Subquery expressions looks like it would be just easier to write SQL, instead of going through the Django ORM. This is where SQL starts to show its expressive strength over ORMs.

jsmeaton 10y ago
You're right, except for when you need to support multiple database backends. For projects it's usually not a concern, but for libraries it certainly is. The ORM has been slowly adding more and more complex types (Expressions) for more complex use cases, which can be mostly ignored for regular CRUD apps.
- mozumder 10y ago
  Aren't SQL subqueries pretty much standard across all databases anyways? Why would writing them in Django's ORM be more compatible?
  - jsmeaton 10y ago
    Field names, table names, quotes or not - a few examples of things that can differ. The syntax of subqueries themselves are standard AFAIK. Building subqueries inside Django gives the rest of Django access to them for things like aggregation or filters.
Alex3917 10y ago
If you already know SQL but don't know any Django, then yes. But if you already know all the other Django model functionality and it's just a matter of learning the new Subquery syntax, then it's probably easier to do in the ORM. There is definitely a benefit to querying everything the same way if you can, so that way it's easy to grep where different tables are being accessed. Cuts down on bugs, security issues, etc.
Waterluvian 10y ago
Absolutely. The amount of "magic" Django does slowly became a real detractor for me. The way I define queries by using a custom language in the form of keyword arguments makes me wonder why I don't just learn SQL instead? I would much rather do something like: models.Foo.objects.filter(sql=my_sql_query_str) Instead of something like: models.Foo.objects.filter(name='bar', parent__siblings__count__lt=3) And no special abstraction on SQL in the form of special classes. Just a string of SQL that I compose with Python string formatting. SQL isn't scary. I don't see the need to try and hide it.
- metaphorm 10y ago
  https://docs.djangoproject.com/en/1.10/topics/db/sql/#django.db.models.Manager.raw https://docs.djangoproject.com/en/1.10/topics/db/sql/#django... you can already do this. the django ORM has a convenient and expressive API for a lot of very common types of queries, but lets you easily drop back into raw SQL when you have a high complexity query that you want to write by hand.
  - jsmeaton 10y ago
    Raw requires a primary key to be returned so it can rebuild the model object for you. You could also use django.db.connection.cursor() directly.
- Alex3917 10y ago
  > Where I assemble a SQL query string using string formatting and vanilla Python. You can just add various filter conditions to a dictionary, and then unpack them into the filter as kwargs. That way you can still build up the dictionary using if/else blocks or however you would normally build up a SQL query string. SQL isn't scary, but for simple queries the Django ORM usually a lot more legible if you take the time to learn the DSL.
- symlinkk 10y ago
  > Just a string of SQL that I compose with Python string formatting sounds like an SQL injection waiting to happen
ksri 10y ago
Take a look at JinjaSQL - https://github.com/hashedin/jinjasql https://github.com/hashedin/jinjasql. Beyond a certain complexity, Django ORM gets in the way. Constructing SQL by hand is painful and can lead to SQL injection. And that's where JinjaSQL shines. You write your query as a string template, and then jinjasql interpolates the variables and provides the bind parameters. Makes it easy to maintain complex queries.
- bradmwalker 10y ago
  http://docs.sqlalchemy.org/en/latest/core/ http://docs.sqlalchemy.org/en/latest/core/
andybak 10y ago
I learnt SQL before learning any ORM but the Django ORM just 'fits my brain' better. Especially when you factor in the fact that it handles 90% of common cases with a very simple syntax. In fact - due to lazy evaluation you can combine simple ORM queries and quite often you end up with subqueries behind the scenes. The Aggregate/Annotate syntax is a wonderful thing and I often find myself surprised writing queries that have some of that "Just Do What I Mean" magic. Admittedly I rarely have to deal with the need for highly performant database code. But one could argue that performance problems are often better handled via caching or denormalisation (which really boil down to the same thing) than by clever work on the db side.
- brianwawok 10y ago
  It is my favorite ORM out there. Maybe a little too easy to do accidental joins, but you can do that in SQL too.
danpalmer 10y ago
I'm not sure I agree. For crossing the boundary from the database to Python objects, I think the ORM is far more expressive than SQL. Sure the query might not be as nice, but the query is only half of the process, there's all the serialisation/deserialisation, injection protection, assignment to Python objects, possible lazy query interfaces, etc.

jitl 10y ago

Release notes with the new features in 1.11: https://docs.djangoproject.com/en/dev/releases/1.11/ https://docs.djangoproject.com/en/dev/releases/1.11/ Highlights: - better support for creating indexes on your Models with class-based indexes - widget rendering in forms now uses the templating system instead of python - Explicit subquery expression support via Subquery and Exists expressions.

jsmeaton 10y ago
Some more important notes (IMO): - Long Term Support - Last release to support Python 2 - Server side cursors for postgres
aptwebapps 10y ago
widget rendering in forms now uses the templating system instead of python I haven't looked at how it's implemented yet, but that sounds like a real godsend.
- collinmanderson 10y ago
  There's now a get_context() method which returns a dict of useful info. the render() method takes that and applies it to widget.template_name.
- legostormtroopr 10y ago
  I have looked at it, and it is a godsend.
- Buetol 10y ago
  They did the same with the login views, they are now class-based and easy to customize. Very useful when you have an exotic templating engine for example and can't inherit the `registration/login.html` template
collinmanderson 10y ago
> The cached template loader is now enabled if DEBUG is False This should give a decent performance improvement for many websites.

bedros 10y ago

my favorite feature so far is search, this is first LTS release with search support builtin (was introduced in 1.10) https://docs.djangoproject.com/en/1.10/ref/contrib/postgres/search/ https://docs.djangoproject.com/en/1.10/ref/contrib/postgres/...

wjdp 10y ago
Rather looking forward to this. Got a number of use cases that don't justify using a 'proper' search engine but would really benefit from a more flexible search than an icontains filter.
- legostormtroopr 10y ago
  Have you had a look at Whoosh and Haystack? Whoosh is pure python and Haystack is a nice Django-like wrapper around search engines. * whoosh.readthedocs.io * haystacksearch.org

pmulv 10y ago

This is a bit off topic, but can anyone suggest a decent Django tutorial? I've just recently learned python, and would like to build a few projects using Django. I completed Django's official tutorial[1], but when it came time for me to actually start building something, I found I didn't really understand what was going on. I should mention I'm inexperienced in both web application development and python in general. 1: https://docs.djangoproject.com/en/1.10/intro/tutorial01/ https://docs.djangoproject.com/en/1.10/intro/tutorial01/

phodo 10y ago
A bit of googling and you will find many excellent resources - filter on 'last year' in the search results. One recommended book is 'two scoops of Django'. You should get familiar with the request response cycle (Language agnostic) and that will make things a lot clearer as you build up your skills.
- pen2l 10y ago
  Two scoops is an okay book I suppose, but it's definitely not what the grandparent post is asking for -- it goes over things too quickly. I actually recommend youtube video tutorials! Like, some will show you how to make a basic photo hosting site... a blog site, etc. Follow those once or twice, and take it from there. Best of luck!
dtran 10y ago
I highly recommend Two Scoops of Django and have recommended to every engineer at my company. The one caveat would be that the newest edition is for Django 1.8, so it'd be good to check against the docs periodically if anything looks off. Off the top of my head, the main thing I'd keep an eye out for would be changes to Class-Based Views like permissions mixins, although if I remember correctly, most of those changes were just moving things in django-braces to Django core.
- legostormtroopr 10y ago
  Danny and Audrey are busy updating two-scoops for version 1.11, so if you can hold off on buying, do so, simply because 1.11 will be the next LTS release.

yeukhon 10y ago

> The Django 1.11.x series is the last to support Python 2. The next major release, Django 2.0, will only support Python 3.5+. Really the most important part of this release, out of all. This is the time where enterprise companies using Python and Django really need to switch to Python 3. In fact, anyone using Ubuntu 16.04 should already find themselves going "ugh" because they needed Python 2. More reasons to push forward.

ProblemFactory 10y ago
I like the model of https://railslts.com/ https://railslts.com/ It's reasonable that volunteer developers working on an open-source project sunset old versions, and old versions of language runtimes or dependencies. Nobody wants to keep maintaining 5-year-old versions with 12-year-old dependencies when they could use their time to improve the latest version instead. Django is one of the most "responsible" projects in this regard - having LTS releases that are maintained for three years for free. Some projects even say "you should stick with github master" for fixes :) But it's cool that Rails has a company providing paid enterprise support after the community support ends. Their pricing is surprisingly cheap - I would expect that if an enterprise has a legacy application that must be kept "stable" and never upgraded, then they would be willing to pay $10k and upwards per month for that privilege.
- collinmanderson 10y ago
  Yes, very likely 1.11 will end up getting unofficial community support after 2020. Django 1.6 (the last version to support Python 2.6) is still getting unofficial support: https://github.com/beanbaginc/django https://github.com/beanbaginc/django
- jsmeaton 10y ago
  I'd be very surprised if there wouldn't be a market for unofficial support of older Django versions - especially 1.8 or 1.11 in the future. It wouldn't be a 'sexy' company, but it'd make money and please a lot of big businesses.

vosper 10y ago

I've been building a project with Django Rest Framework (DRF), it's my first time using anything Django-related. Does anyone know whether new versions of Django tend to drop right into DRF, or whether DRF has to do some work to be compatible with a new version? I ask because I like the sound of the fulltext search mentioned in another comment, because it would mean I don't have to install a search engine to support that feature. So I'd switch to Postgres and start using Beta 1 pretty soon, if DRF will just-work with it.

oliwarner 10y ago
I really don't mean this in as aggressive a way as it might read without this prefix but... Why don't you just try it?
- vosper 10y ago
  I guess I could try grabbing the beta with pip, and I suppose there's probably some test suite for DRF that I could find and run. The thing I don't know for sure is that if the test suite passes then I'm good to go.
  - StavrosK 10y ago
    Things generally tend to break loudly, so if your test suite (for your app) passes, you should be good to go.
orf 10y ago
Yes, they generally work really well. You could give it a spin and report any issues you may find in the alpha to the DRF team :)
pythonaut_16 10y ago
I would try it in development, run your tests, etc. But wait to deploy anything to production until DRF officially supports it (which should be pretty much at launch, DRF should be working with the beta now to ensure compatibility)
10y ago

jbub 10y ago

Class based indexes - looks great, is there support for CREATE INDEX CONCURRENTLY for postgres ?

rowanseymour 10y ago
I also wondered that but seems from https://code.djangoproject.com/ticket/21039 https://code.djangoproject.com/ticket/21039 they'd prefer devs to do that manually in migrations marked as non-atomic
- brianwawok 10y ago
  Makes sense, would be weird to start testing while indexes are building
  - rowanseymour 10y ago
    CONCURRENTLY doesn't build indexes asynchronously - it just builds them in a way that doesn't lock the table.
    - brianwawok 10y ago
      Oh I thought it returned control after you hit it.

omegote 10y ago

The new way of rendering form widgets is something I've been waiting for a long time. Now using custom form widgets like those in Bootstrap, or more complex fields like datepickers and the like should be as easy as dropping the HTML templates for those widgets in the proper folder, which is great.