QuerySet Deep Dive: Q, F & Lookups

A QuerySet is a lazy, chainable collection of database rows that Django builds up as Python objects and only sends to the database as a single SQL query when you finally iterate, slice, or evaluate it.

Learn QuerySet Deep Dive: Q, F & Lookups in our free Django course — a beginner-friendly interactive lesson with worked examples, a practice exercise and a…

Part of the free Django course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

In this lesson you'll master the tools that make QuerySets powerful: field lookups like __gte and __icontains, Q objects for OR/AND/NOT logic, F expressions for field-to-field comparisons and atomic updates, and the laziness that ties it all together.

A field lookup is the double-underscore suffix you attach to a field name to say how to compare it. filter() keeps rows that match, exclude() drops them, and because every QuerySet method returns a new QuerySet you can chain them. Keyword arguments inside one call are always combined with AND .

Each lookup maps directly to a piece of the generated SQL WHERE clause:

Plain filter() arguments can only be AND-ed together, so for OR logic you wrap each condition in a Q object and combine them with | (OR), & (AND), and ~ (NOT). A Q is a reusable bundle of conditions you can build up and pass around.

You can also build a Q up dynamically and only run the query once it is complete:

An F expression refers to a field's current value in the database , so the work happens in SQL rather than Python. That unlocks two things: field-to-field comparisons (compare one column to another) and atomic updates that are safe even when many requests run at once.

The reason chaining all of this is cheap is that a QuerySet is lazy . Building it does nothing; the database is only hit when you force evaluation:

Fill in the blank so the lazy query only "runs" when you force evaluation with the method that returns its rows.

Chaining .filter(a=1).filter(b=2) gives you AND, not OR, so you get far fewer rows than expected.

✅ Fix: use a Q object — filter(Q(a=1) | Q(b=2)) — for true OR logic.

You misspelled the lookup or used a single underscore, so Django reads views_gte as a field name.

✅ Fix: use a double underscore — views__gte — between the field name and the lookup.

❌ Incrementing with obj.views += 1 loses updates

Reading into Python then saving lets two concurrent requests overwrite each other's count.

✅ Fix: use an atomic update with an F expression — .update(views=F("views") + 1) .

Put it all together: select the posts that are featured OR popular, then bump each one's views the way an F expression would in a single atomic update.

Lesson complete — you can write expressive, efficient queries!

You can now reach for field lookups like __gte and __icontains , chain filter() and exclude() , express OR/AND/NOT with Q objects, compare and atomically update fields with F expressions, and explain why a QuerySet stays lazy until it is evaluated.

🚀 Up next: Aggregation & Annotation — summarise and compute over whole QuerySets with Count, Sum, and annotate().

Practice quiz

• Browse all free courses
• Cheat sheets & quizzes
• Coding dictionary