as subqueries in order to work around SQLite's lack of support for this
syntax, is lifted when SQLite version 3.7.16 or greater is detected.
fixes#3634
- The workaround for SQLite's unexpected delivery of column names as
``tablename.columnname`` for some kinds of queries is now disabled
when SQLite version 3.10.0 or greater is detected.
fixes#3633
itself as a "Could not locate column" error when using
:class:`.Query` to select from multiple, anonymous column
entities when querying against SQLite, as a side effect of the
"join rewriting" feature used by the SQLite dialect.
fixes#3241
as a scalar subquery such as within an IN would receive inappropriate
substitutions from the enclosing query, if the same table were present
inside the subquery as were in the enclosing query such as in a
joined inheritance scenario.
fixes#3130
Leave this test in place as its ultimately a SQLite use case, but only test on SQLite.
We perhaps should add another test case that works on all platforms.
implemented right before the release of 0.9.3 affected the case where
a UNION contained nested joins in it. "Join rewriting" is a feature
with a wide range of possibilities and is the first intricate
"SQL rewriting" feature we've introduced in years, so we're sort of
going through a lot of iterations with it (not unlike eager loading
back in the 0.2/0.3 series, polymorphic loading in 0.4/0.5). We should
be there soon so thanks for bearing with us :).
fixes#2969 re: #2967
- solve the issue of join rewriting inspecting various types of
from objects without using isinstance(), by adding some new
underscored inspection flags to the FromClause hierarchy.
🎫`2369` and 🎫`2587` where a nested join with one side
already an aliased select would fail to translate the ON clause on the
outside correctly; in the ORM this could be seen when using a
SELECT statement as a "secondary" table. [ticket:2858]
are transferred correctly for when .key is present; tests have been enhanced
to test this condition for render, result map construction, statement
execution. [ticket:2790]
the joins as is, regardless of the dialect not supporting it. use_labels=True
indicates a higher level of automation and also can maintain the labels
between rewritten and not. use_labels=False indicates a manual use case.
Mike Bayer