Django 1.11 beta 1 released | Hacker News Reader

Django 1.11 beta 1 released

djangoproject.com

167 pointstweakz86 comments

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/

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.

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!

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.

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.

Two Scoops is a great book, and my personal go to reference for best practices. But I don't know if I would recommend it for someone looking to learn Django for the first time as it is more of a reference.

For someone completely new to Django I'd likely recommend Tango with Django or Hello Web App

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.

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

I'll chime in with also highly recommending the Two Scoops book! It was nice to see their design philosophy. I worked with several older releases of Django and found their thoughts on CBV helpful in deciding when/when not to use them. Also, it was nice to see their thoughts on layout. I stepped away from Django development for awhile and a lot has changed from 1.6 to 1.10! I just wish that they had decided to also offer an electronic version! Any idea if they are planning an electronic release this time?

newboston on youtube. I needed a crash course on django -- after the first couple of videos I knew what I needed. But, I got hooked by his fast pace and finished the set over 2 days. A+

As far as youtube tutorials go, I thought sentdex had a pretty good one: https://www.youtube.com/playlist?list=PLQVvvaa0QuDeA05ZouE4O... . It helped me get my first django project up and running.

I recommend TreeHouse's Django series. I tried other methods (books, blog posts, none really helped me). Not free either, but it really helped. There's a free trial so you can learn Django quickly in 7 days (I did) but I am keeping my membership for now to learn other stuff... (although kinda pricey for me). The series is not up-to-date either, but the basics remain unchanged. You may find one or two syntax / API differences, but that's it.

I also grew up with Django... since 0.9 but didn't really focus on web development using Django, so for me I had to pick it up again from scratch and quick. Two Scoops is a reference book at best IMO. Use it if you are really comfortable with all the basics of Django and you have done at least 6-12 months of Django regularly.

this youtube tutorial helped me a lot

https://www.youtube.com/watch?v=oT1A1KKf0SI&list=PLxxA5z-8B2...

I really dig MDN's tutorial: https://developer.mozilla.org/en-US/docs/Learn/Server-side/D...

I haven't followed this one myself, but the django girls tutorial is supposed to be excellent.

https://tutorial.djangogirls.org/en/

can confirm this tutorial is good, covers setting up virtual env for python / easy to follow

I prefer djangogirls to two scoops - twoscoops is the way to go once you have learn the basics. But I felt it lacked a walkthru example

Two Scoops is a great book, but it is based around best practices, so assumes you know Django already to some extent.

yes I agree - its where you should aspire to be

Yes, django girls is very good. They use it for workshops, see where people run into trouble, and then adapt. So it's very well battle tested.

This is a very helpful one, I used it a lot and referred to it a lot when building out my first few Django apps.

I've been learning Django and found that most tutorials are out of date and very few go into detail. Two scoops even breezed over some aspects of the new project environment decisions they recommend (and share on Github). I've turned to asking for help from experts and on occasion hiring a mentor on sites like code mentor to answer questions for me.

Beats the cost of a coding academy and has let me go at my own pace.

I highly recommend the Django Unchained[1] course from Tuts+, that's my favorite introduction to Django, where you learn the fundamentals by building a HN clone.

Also, a shameless plug, I have built a website[2] where I collect the best webdev learning resources, you can find other good Django tutorials there. Funny enough, the website itself is built based on the stuff I've learned from the Django Unchained course =)

[1] https://code.tutsplus.com/courses/django-unchained

[2] http://webacademy.io/django-tutorials/

You should enable HTTPS on this asap. Let's Encrypt[0] makes it super easy, and Digital Ocean has some good tutorials as well.

Besides that it looks really good!

[0] https://letsencrypt.org/

Thank you very much for the advice, I will definitely do that!

Obey The Testing Goat is good. It follows TDD and is pretty complete

http://www.obeythetestinggoat.com/pages/book.html#toc

Release notes with the new features in 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.

Some more important notes (IMO):

  - Long Term Support    
  - Last release to support Python 2  
  - Server side cursors for postgres

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.

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.

I have looked at it, and it is a godsend.

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

> The cached template loader is now enabled if DEBUG is False

This should give a decent performance improvement for many websites.

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.

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

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.

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

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.

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?

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.

Things generally tend to break loudly, so if your test suite (for your app) passes, you should be good to go.

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

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)

DRF and the Django team work pretty closely together. It's a well-supported project.

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

I like the model of 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.

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

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.

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.

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.

Aren't SQL subqueries pretty much standard across all databases anyways? Why would writing them in Django's ORM be more compatible?

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.

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.

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.

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.

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.

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

> Just a string of SQL that I compose with Python string formatting

sounds like an SQL injection waiting to happen

Hah!! So so true.

I posted elsewhere on this thread, but take a look at JinjaSQL - https://github.com/hashedin/jinjasql. Let's you generate SQL from a string template without worrying about SQL injection.

Yep. I'm wondering if a framework would ever adopt something like Records [1].

1: https://github.com/kennethreitz/records (same author as Requests)

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

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

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.

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.

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.

    Post.objects.prefetch_related('author__company')

Often I want to avoid joins on big tables but still need to prefetch related fields on the objects I'm fetching. Example above fetches all the authors for the returned post, and then fetches all their companies. That's two additional fetches I don't have to write.

It's also simple to prefetch in SQL. For example, if you wanted to populate a temp table with the results of a select query in SQL Server, this can be a one line change:

http://stackoverflow.com/a/12323794

I like this:

    published_posts = Post.objects.filter(publish_date__gte=now())
    post_count = published_posts.count()

You can't just append a COUNT to an SQL query, you'd have to write two queries, or one query that returned both. The above code produces two different queries, so it's much more composable.

I use it for tacking on extra filtering terms as well:

    if category:
        published_posts = published_posts.filter(category=category)

This is simple in SQL. There are multiple ways of doing it. For example, using a GROUP BY...

SELECT published_posts, COUNT(published_posts) FROM Table1 WHERE publish_date > '2017-02-20' GROUP BY published_posts

The above query generates SQL in the end. My point was that SQL is not composable, whereas the above is.

Yea, that's true. This is the most important part most programmers forget about. You need to know SQL to be able to fully use any ORM. It doesn't mean that you have to write SQL when using an ORM.

Try giving pyramid + sqlalchemy a shot. Way less magic, everything feels very pythonic and its a very mature stack that can scale really well.

You may be interested in the `.extra(...)` call on a QuerySet in Django. It allows you to specify hand-written SQL for various clauses, including `WHERE`.

https://docs.djangoproject.com/en/1.10/ref/models/querysets/...

There's also a method (I forget the name, as I've never used it) where you write the full SQL and just tell Django which models' rows it's supposed to be returning, and it will build model instances from the returned SQL. Pretty nifty.

It is the raw() function: https://docs.djangoproject.com/en/1.10/topics/db/sql/#passin...

Take a look at 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.

http://docs.sqlalchemy.org/en/latest/core/

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.

It is my favorite ORM out there. Maybe a little too easy to do accidental joins, but you can do that in SQL too.

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.

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

I also wondered that but seems from https://code.djangoproject.com/ticket/21039 they'd prefer devs to do that manually in migrations marked as non-atomic

Makes sense, would be weird to start testing while indexes are building

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

Oh I thought it returned control after you hit it.

Reply on news.ycombinator.com