one issue is that we can't get rid of mapper-level with_polymorphic as that's a very useful feature. Most of the complexity of aliased=True is also used for with_polymorphic.

it's still worth getting rid of it just doesn't take that much code out of query.py.

Update, it does, because aliased=True / from_joinpoint are the only reason we need to be applying adaptation per call to filter(), having(), order_by(), group_by(). Without them, all the adaption becomes at once when we create the SELECT, that is, we can move it all to one single adaption to ._whereclause , ._order_by etc. This means we can unify with base select() way more easily, we can use the same methods for base select() as we do for ORM select() and we greatly reduce call overhead. it's getting close to where we need to have 2.0 going at the same time.

Here is another form_joinpoiint use case that would have to go away:

            OrderAlias = aliased(Order)

            sess.query(User, OrderAlias, Item.description)
            .join(OrderAlias, "orders")
            .join("items", from_joinpoint=True)
            .filter_by(description="item 3")
            .order_by(User.id, OrderAlias.id)

so in that case, the assertion needs to encourage them to do:

            sess.query(User, OrderAlias, Item.description)
            .join(OrderAlias, "orders")
            .join(Order.items, )

which means we start to have to deprecate the whole concept of join() accepting string relationship names and then the whole idea of join("a", "b", "c", ..) should go as well, certainly in 2.0 that should be gone. that's a big change.

this use case has to be depreacted as well so that more implicit aliasing can be removed:

            sess.query(Company)
            .join(people.join(engineers), Company.employees)
            .filter(Engineer.name == "dilbert"),

the correct pattern should be:

            pjoin = with_polymorphic(Person, [Engineer])
            sess.query(Company)
            .join(pjoin, Company.employees)
            .filter(Engineer.name == "dilbert"),

or join(Company.employees.of_type(pjoin))

I want to see if I can do these deprecations first, and get the tests set up, before I merge https://gerrit.sqlalchemy.org/c/sqlalchemy/sqlalchemy/+/1599 . this means I'll have to port to 1599 but I want this basic set of deps to be set up before we take a huge left turn with 1599.

Mike Bayer referenced this issue:

Unify Query and select() , move all processing to compile phase https://gerrit.sqlalchemy.org/c/sqlalchemy/sqlalchemy/+/1599

we don't need to deprecate multi-join as Query is legacy overall in any case.

Mike Bayer has proposed a fix for this issue in the master branch:

Deprecate strings indicating attribute names https://gerrit.sqlalchemy.org/c/sqlalchemy/sqlalchemy/+/2303

we don't need to deprecate multi-join as Query is legacy overall in any case.

ah we've already documented it https://docs.sqlalchemy.org/en/14/changelog/migration_20.html#orm-query-chaining-using-lists-of-attributes-rather-than-individual-calls-removed