summaryrefslogtreecommitdiff
path: root/tools/generate_proxy_methods.py
Commit message (Collapse)AuthorAgeFilesLines
* refactor code generation tools , include --check commandMike Bayer2023-01-181-49/+32
| | | | | | | | | | | | | | | | | in particular it looks like CI was not picking up on the "git diff" oriented commands, which were failing to run due to pathing issues. As we were setting cwd for black/zimports relative to sqlalchemy library, and tox installs it in the venv, black/zimports would fail to run from tox, and since these are subprocess.run we didn't pick up the failure. This overall locks down how zimports/black are run so that we are definitely from the source root, by using the location of tools/ to determine the root. Fixes: #8892 Change-Id: I7c54b747edd5a80e0c699b8456febf66d8b62375
* Improve typings of execution optionsFederico Caselli2022-11-021-1/+2
| | | | | Fixes: #8605 Change-Id: I4aec83b9f321462427c3f4ac941c3b272255c088
* Improve proxy methods with the changes from the abandonedFederico Caselli2022-10-181-2/+5
| | | | | | I5c7f172e5224fa08d0675160ac919d0b045a26eb Change-Id: Ieb7971297f959fd635a4627bd93154e28ef0ef2b
* use black 22.8.0Mike Bayer2022-10-031-2/+2
| | | | | | | nothing happened moving from 22.3 to 22.8. a full run of pre-commit found some little things in the generate_proxy_methods script. Change-Id: Ie6b4235b87bbfcb252759c0afb133ab8d0cf51db
* pep484 ORM / SQL result supportMike Bayer2022-04-271-38/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | after some experimentation it seems mypy is more amenable to the generic types being fully integrated rather than having separate spin-off types. so key structures like Result, Row, Select become generic. For DML Insert, Update, Delete, these are spun into type-specific subclasses ReturningInsert, ReturningUpdate, ReturningDelete, which is fine since the "row-ness" of these constructs doesn't happen until returning() is called in any case. a Tuple based model is then integrated so that these objects can carry along information about their return types. Overloads at the .execute() level carry through the Tuple from the invoked object to the result. To suit the issue of AliasedClass generating attributes that are dynamic, experimented with a custom subclass AsAliased, but then just settled on having aliased() lie to the type checker and return `Type[_O]`, essentially. will need some type-related accessors for with_polymorphic() also. Additionally, identified an issue in Update when used "mysql style" against a join(), it basically doesn't work if asked to UPDATE two tables on the same column name. added an error message to the specific condition where it happens with a very non-specific error message that we hit a thing we can't do right now, suggest multi-table update as a possible cause. Change-Id: I5eff7eefe1d6166ee74160b2785c5e6a81fa8b95
* pep-484: session, instancestate, etcMike Bayer2022-04-121-6/+20
| | | | | | | | Also adds some fixes to annotation-based mapping that have come up, as well as starts to add more pep-484 test cases Change-Id: Ia722bbbc7967a11b23b66c8084eb61df9d233fee
* use code generation for scoped_sessionMike Bayer2022-04-121-0/+413
our decorator thing generates code in any case, so point it at the file itself to generate real code for the blocks rather than doing things dynamically. this will allow typing tools to have no problem whatsoever and we also reduce import time overhead. file size will be a lot bigger though, shrugs. syntax / dupe method / etc. checking will be accomplished by our existing linting / typing / formatting tools. As we are also using "from __future__ import annotations", we also no longer have to apply quotes to generated annotations. Change-Id: I20962cb65bda63ff0fb67357ab346e9b1ef4f108