r"""Create a SQL JOIN against this :class:`_query.Query` object's criterion and apply generatively, returning the newly resulting :class:`_query.Query`. **Simple Relationship Joins** Consider a mapping between two classes ``User`` and ``Address``, wi
(
self,
target: _JoinTargetArgument,
onclause: Optional[_OnClauseArgument] = None,
*,
isouter: bool = False,
full: bool = False,
)
| 2270 | @_generative |
| 2271 | @_assertions(_no_statement_condition, _no_limit_offset) |
| 2272 | def join( |
| 2273 | self, |
| 2274 | target: _JoinTargetArgument, |
| 2275 | onclause: Optional[_OnClauseArgument] = None, |
| 2276 | *, |
| 2277 | isouter: bool = False, |
| 2278 | full: bool = False, |
| 2279 | ) -> Self: |
| 2280 | rclass="st">"""Create a SQL JOIN against this :class:`_query.Query` |
| 2281 | object&class="cm">#x27;s criterion |
| 2282 | and apply generatively, returning the newly resulting |
| 2283 | :class:`_query.Query`. |
| 2284 | |
| 2285 | **Simple Relationship Joins** |
| 2286 | |
| 2287 | Consider a mapping between two classes ``User`` and ``Address``, |
| 2288 | with a relationship ``User.addresses`` representing a collection |
| 2289 | of ``Address`` objects associated with each ``User``. The most |
| 2290 | common usage of :meth:`_query.Query.join` |
| 2291 | is to create a JOIN along this |
| 2292 | relationship, using the ``User.addresses`` attribute as an indicator |
| 2293 | for how this should occur:: |
| 2294 | |
| 2295 | q = session.query(User).join(User.addresses) |
| 2296 | |
| 2297 | Where above, the call to :meth:`_query.Query.join` along |
| 2298 | ``User.addresses`` will result in SQL approximately equivalent to: |
| 2299 | |
| 2300 | .. sourcecode:: sql |
| 2301 | |
| 2302 | SELECT user.id, user.name |
| 2303 | FROM user JOIN address ON user.id = address.user_id |
| 2304 | |
| 2305 | In the above example we refer to ``User.addresses`` as passed to |
| 2306 | :meth:`_query.Query.join` as the class="st">"on clause", that is, it indicates |
| 2307 | how the class="st">"ON" portion of the JOIN should be constructed. |
| 2308 | |
| 2309 | To construct a chain of joins, multiple :meth:`_query.Query.join` |
| 2310 | calls may be used. The relationship-bound attribute implies both |
| 2311 | the left and right side of the join at once:: |
| 2312 | |
| 2313 | q = ( |
| 2314 | session.query(User) |
| 2315 | .join(User.orders) |
| 2316 | .join(Order.items) |
| 2317 | .join(Item.keywords) |
| 2318 | ) |
| 2319 | |
| 2320 | .. note:: as seen in the above example, **the order in which each |
| 2321 | call to the join() method occurs is important**. Query would not, |
| 2322 | for example, know how to join correctly if we were to specify |
| 2323 | ``User``, then ``Item``, then ``Order``, in our chain of joins; in |
| 2324 | such a case, depending on the arguments passed, it may raise an |
| 2325 | error that it doesn&class="cm">#x27;t know how to join, or it may produce invalid |
| 2326 | SQL in which case the database will raise an error. In correct |
| 2327 | practice, the |
| 2328 | :meth:`_query.Query.join` method is invoked in such a way that lines |
| 2329 | up with how we would want the JOIN clauses in SQL to be |