The .c attribute on a SQLAlchemy select() object implicitly
creates an unnamed subquery when invoked, and the columns
returned are in reference to this subquery, not the SELECT
statement itself. The usefulness of
this subquery is close to zero, whereas it confuses users
with its misleading behaviors, complicates the internals,
and is rejected by the two leading databases (PostgreSQL and
MySQL) at the SQL level in any case, and as such it's going
away most likely in SQLAlchemy 1.4, after
a short deprecation period that has yet to be announced in the 1.3
series.
Keystone's schema-oriented unit tests appear to be applying
the select() construct to a Table object that's been reflected with
autoload for the usually immediate purpose of iterating through
the columns of this Table and comparing them to a set of
comparison tuples, however the ".c." collection
is available on all "from clause" objects of which Table is a
member so there is no need to apply a select() first. In particular,
there is a reference to an internal
SQLAlchemy API "_proxies" which is attempting to reconcile the
fact that the implicitly created subquery columns don't refer
to the original Table column's "default" parameter (there is in fact
a public API for this system as well, but it is not needed
once the select() is removed).
This patch removes the "select()" applied to the Table returned
by select_table() and renames the method to load_table() to more
accurately reflect what this method does. The use of SQLAlchemy's
private "_proxies" API can now be removed, and the two occurrences
where the select() were actually used to invoke a SELECT
statement are replaced with explicit
production of a select() construct as well as making use of the
already-present Session to invoke the query rather than using
an out-of-band ad-hoc transaction (connectionless execution is
also going away by SQLAlchemy 2.0 in any case).
Change-Id: Ica7037541a1305308ed743d8e04a3c2f02a2b811
48594eddea