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