
Django 1.11 beta 1 released - tweakz
https://www.djangoproject.com/weblog/2017/feb/20/django-111-beta-1-released/
======
pmulv
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/)

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

~~~
jgalt212
I think this book is generally good, but I am not a fan of their espousal of
class based views. HTTP is not class based, it's functionally based.

~~~
notsrg
If your Django project is a million lines of code you're going to appreciate
mixins and CBV's. Most built in views are moving to CBV's as well (see
login/logout/password reset/etc in 1.11).

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

~~~
aptwebapps
_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.

~~~
Buetol
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

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

------
bedros
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/...](https://docs.djangoproject.com/en/1.10/ref/contrib/postgres/search/)

~~~
wjdp
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
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

------
vosper
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
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
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
Things generally tend to break loudly, so if _your_ test suite (for your app)
passes, you should be good to go.

------
yeukhon
> 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
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
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)

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

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

~~~
Daishiman
> 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?

You _have_ to learn SQL to use the Django ORM anyways; it's required knowledge
in order to be able to wield the higher level abstraction effectively.
However, the way you write a lot of these things in SQL is substantially more
verbose and harder to compose.

~~~
ZenoArrow
>"However, the way you write a lot of these things in SQL is substantially
more verbose and harder to compose."

Could you give an example of something that's hard to compose with SQL? I'm
sure ORMs have their advantages, I just want to understand how much benefit I
could get from using one.

~~~
MatthewWilkes
Queries across joins are the simple example. The ORM takes care of the join
bit for you so you can write:

    
    
        Book.objects.filter(author__address__country='GB')
    

Rather than having to manage the joins with the author and address tables
yourself.

~~~
ZenoArrow
With that example, do you have control over how the records are joined?

For example, in SQL if I wanted to return records where an records could be
found in both tables, I would use an inner join, whereas if I wanted to return
all records from 'author' and any related information from 'address' (and
return NULL if a suitable address entry couldn't be found) I could use a left
join. Does the ORM you have in mind give you that flexibility?

It's probably worth mentioning that some SQL tools will suggest fields that
can be joined on, if this is a concern.

~~~
jsmeaton
Django will generate a LEFT JOIN for nullable keys, and an INNER JOIN for non
nullable keys. The lack of control over joins and conditions is a weakness of
the ORM, but Django generally does the right thing. Of course, you can do an
`__isnull` on the relation to create a pseudo inner join from the generated
LEFT JOIN, but admit it's not the same.

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

~~~
rowanseymour
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
Makes sense, would be weird to start testing while indexes are building

~~~
rowanseymour
CONCURRENTLY doesn't build indexes asynchronously - it just builds them in a
way that doesn't lock the table.

~~~
brianwawok
Oh I thought it returned control after you hit it.

