select / query unification

[zzzeek]

building on the "move compile context to compile" at https://gerrit.sqlalchemy.org/#/c/sqlalchemy/sqlalchemy/+/1599/

Query needs to be a Select, and select() and query() constructs need to share as much code as possible as far as how they collect state:

1. both will accumulate _criterion, _order_by, _group_by, _from_obj as tuples that build up

2. for select compile, dont use clauselist at all. Accessors like select._wherecllause, select._order_by_clause will create a ClaustList on the fly for backwards compatibility. but compiler will use:

text = self.render_tuple_with_separator(select._order_by, ",")
text = self.render_tuple_with_separator(select._criterion, "AND")

that way there is no expense or need to create ClauseList; the tuples already consist of arguments that have been vetted at construction time.

3. Query has to subclass Select or some similar construct

4. _compile_context does all the work in the above gerrit and is somehow triggerde from compilation; i think hardwiring a _process() method on the object can do this

5. select() may or may not do the same thing

from the above, we hope to have:

1. Query and select() are super cheap to build

2. compilation of select() remains super cheap too, don't even bother with ClauseList

3. all of Query compile_context moves to act within the compile phase

from there we can do #4639 have both be cached on cache key

[zzzeek]

we can remove:

1. from_self(). the thing this accomplishes can be done more explicitly with aliased()

2. select_from_entity(). same

this combined with #4705 we should be able to remove all adaption from Query / QueryContext.

at the moment I might want to build out the ORM context for select() directly first and try to improve upon the work done in I19e05b3424b07114cce6c439b05198ac47f7ac10 as much as possible, building from scratch with all of the old assumptions removed.

[zzzeek]

at the moment, 2.0 only needs to have select(), just once. there does not need to be any ORM specific front-facing construct, meaning, there is no Query. This will take the presssure off of 1.4 for Query to be a different kind of object, we can leave it mostly or entirely the way it is, if that turns out to be better.

when you have a select(), the entities if they are ORM entities will have an annotation "context_plugin", which points to a CompileState class that should be used when this object is compiled. Only the first plugin in the list of columns will be used. the coercions system should pull out this plugin right at the outset.

This means if I make a select() against an ORM entity and the ORM entity has joined loaders in it, they'll be in the SQL if for example I say str(statement).

there should be ways to affect the plugins, suppose we have this:

stmt = select(User).join(User.addresses)

that's an ORM join so we need the ORM plugin in order to compile the above construct. Maybe if they want the above without eager loaders we say:

select(User).join(User.addresses).plugin_options(enable_eagerloads=False)

[sqla-tester]

Mike Bayer referenced this issue:

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

[zzzeek]

this is done in dce8c7a .

[sqla-tester]

Mike Bayer referenced this issue:

Propose a single select() construct https://gerrit.sqlalchemy.org/c/sqlalchemy/sqlalchemy/+/2058