SQLAlchemy has a large volume of documentation that's currently using a mix of mostly v1 and some v2 style queries especially when talking with the orm.

For v2, while there is no plan to remove query, most of the docs should adopt the v2 style of doing things.

• session.query -> session.execute/session.scalars
• update Query API docs so that every method refers to background on migrating to the 2.0 pattern, or the corresponding method on Select. general format/ language to use is:

        .. seealso::

            This API is available using :term:`2.0 style` queries as well,
            documented at:

            * :ref:`queryguide_inspection`

• Declarative mappings need to use mapped_column()
• update tutorials to introduce mapped_column(), some tips/etc. regarding "what happened to Column()?" etc. describe they are equivalent Not sure to the extent that the docs will push for “annotation only” style, probably more than less. New dataclasses docs. The existing “dataclasses” approach with sa_field_whatever it’s called becomes legacy.
• new DeclarativeBase should be used everywhere instead of declarative_base() function
• update central mypy docs in ORM guide
• more links in mypy extension to new mypy docs in ORM guide
• document annotation-enabled mapped_column() usage, likely in the ORM tutorial
• remove dead links to removed sections, running the sphinx build shows a lot of warnings to old sections
• Reorganizing mapper config docs further as it’s very hard to follow between declarative/imperative w/ or w/out dataclasses, want to make room for new dataclasses approach.
• update mypy plugin docs with a full deprecation note at the top
• asyncio docs, note with "uses SQLAlchemy’s future mode, which has several potentially breaking changes. " should be reworded or removed for 2.0 docs
• update the section Building Query-Enabled Properties tha does not have a direct 1->2 porting, since the standalone with_parent requires a relationship
• update the error section An alias is being generated automatically for raw clauseelement
• is an equivalent for Query.only_return_tuples needed?
  a: no, as this was a workaround for the fact that Query is hardcoded to list of entities for a single entity. the Result architecture addresses this issue specifically
• is an equivalent for Query.params needed? Select.params is not comparable, since it does a different thing enirely
  a: no, because Query has no execute() method, there was no way to use bindparam() with Query. With sesion.execute(), you just pass the params
• is an equivalent for Query.reset_joinpoint needed?
  a: no, because the primary use for "joinpoint" was to support query.join("stringprop").join("anotherstringprop"), where we didn't know what the "left side" was. join() with a string like that is not part of Select.join(), and it now always has an explicit indication of the "left side" for relationship joins. We also have join_from() for even more indication of "left side" when needed. the other use for "joinpoint" was resetting what filter_by() would be relative towards. a code search through openstack etc. showed that nobody was using reset_joinpoint() at all, so Select.filter_by() is now always relative to the last joined entity. It would be a major change to revise that now and nobody has had any issue with it.
• is an equivalent for Query.enable_eagerloads needed?
  a: not unless someone comes to us with a usecase for it. it was mostly used by Query internally for methods that have other approaches in the newer system, and the logic for rendering joined eager loads or not is now mostly automatic based on the context of the query itself. it really only applies to "joined eager loading" and someone could just as well use a loader option if they have a Select where an unwanted joined eager load is coming out.

The old migration files should not be updated, since there were "current" for an older version of the docs.

Help is very much appreciated in this task, but please check with us for specific sub-tasks as we might be working on some already