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.
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.
Django 1.11 beta 1 released
71–80 of 87 posts
Re: Django 1.11 beta 1 released
#72This 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.…
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.
Re: Django 1.11 beta 1 released
#73This 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.…
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'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?
Re: Django 1.11 beta 1 released
#74Re: Django 1.11 beta 1 released
#75Subquery 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.
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 th…
It is my favorite ORM out there. Maybe a little too easy to do accidental joins, but you can do that in SQL too.
Re: Django 1.11 beta 1 released
#76This 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.…
Obey The Testing Goat is good. It follows TDD and is pretty complete
Re: Django 1.11 beta 1 released
#77I'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 t…
DRF and the Django team work pretty closely together. It's a well-supported project.
Re: Django 1.11 beta 1 released
#78Earlier quoted context omitted.
>"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.
Re: Django 1.11 beta 1 released
#79Earlier quoted context omitted.
>"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.
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:
Re: Django 1.11 beta 1 released
#80Earlier quoted context omitted.
>"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.
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