related_name وعمليات البحث العكسية

You set a ForeignKey from book to author, but you can also walk it backward. A reverse lookup reaches the many side from the one side.

By default Django names the reverse accessor modelname_set. From an author, the books appear as book_set.

That book_set is a full manager, so you can chain filter, order_by, and count on it just like any query.

The _set name is clunky. Set related_name on the ForeignKey to pick a clearer reverse accessor yourself.

Now the reverse reads naturally. Instead of book_set you simply write books, which is far easier to follow.

related_name also drives filter across the link. Use the chosen name with the double underscore from the other model.

If you skip related_name, the reverse query name is the lowercase model name, like author.objects.filter(book__title=...).

Two ForeignKeys from one model to the same target collide on the reverse name. A distinct related_name on each fixes it.

Set related_name to a value ending in + to disable the reverse accessor entirely when you never need it.

You can split the names: related_query_name sets the filter name separately from the attribute used to read related rows.

related_name applies to ForeignKey, ManyToManyField, and OneToOneField alike, so every reverse path can read clearly.

You set related_name="books" on Book's author ForeignKey. How do you list an author's books?

You did it! Reverse lookups walk a link backward, and related_name turns clunky _set accessors into clear, readable names. 🔄