method :meth:`.Query.with_statement_hint` to support statement-level hints that are not specific to a table. fixes #3206
unify everything. - create a new layer of separation between the "from order bys" and "column order bys", so that an OVER doesn't ORDER BY a label in the same columns clause - identify another issue with polymorphic for ref #3148, match on label keys rather than the objects
we're now using; rework them fully so that their behavioral contract is consistent regarding adapter.traverse() vs. adapter.columns[], add a full suite of tests including advanced wrapping scenarios previously only covered by test/orm/test_froms.py and test/orm/inheritance/test_relationships.py - identify several cases where label._order_by_label_clause would be corrupted, e.g. due to adaption or annotation separately - add full tests for #3148
The "anonymize label" logic is now generalized to ClauseAdapter, and takes place when the anonymize_labels flag is sent, taking effect for all .columns lookups as well as within traverse() calls against the label directly. - traverse() will also memoize what it gets in columns, so that calling upon traverse() / .columns against the same Label will produce the same anonymized label. This is so that AliasedClass produces the same anonymized label when it is accessed per-column (e.g. SomeAlias.some_column) as well as when it is applied to a Query, and within column loader strategies (e.g. query(SomeAlias)); the former uses traverse() while the latter uses .columns - AliasedClass now calls onto ColumnAdapter - Query also makes sure to use that same ColumnAdapter from the AliasedClass in all cases - update the logic from 0.9 in #1068 to make use of the same _label_resolve_dict we use for #2992, simplifying how that works and adding support for new scenarios that were pretty broken (see #3148, #3188)
stringify a _label_reference() as is. - add .key to _label_reference(), so that when _make_proxy() is called, we don't call str() on it anyway. - add a test to exercise Query's behavior of adding all the order_by expressions to the columns list of the select, assert that things work out when we have a _label_reference there, that it gets sucked into the columns list and spit out on the other side, it's referred to appropriately, etc. _label_reference() could theoretically be resolved at the point we iterate _raw_columns() but it's better to just let things work as they already do (except nicer, since we get "tablename.colname" instead of just "somename" in the columns list) so that we aren't adding a ton of overhead to _columns_plus_names in the common case.