-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for SQLAlchemy 2.0 #488
Conversation
c3ec061
to
ad595a5
Compare
self.assertEqual(expected_bulk_args, bulk_args) | ||
self.assertSequenceEqual(expected_bulk_args, bulk_args) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With SA<2.0, bulk_args
is a tuple
, so expected_bulk_args
was written as such. Now, with SA>=2.0, it is a list
. Because this only concerns the call arguments to cursor.executemany()
, which is invoked by SQLAlchemy, I think we do not need to put any kind of admonition notice about a breaking change into the changelog, as it looks like it will not concern the user of the library at all.
Please let me know if you think differently.
386e246
to
7ef37c1
Compare
1429658
to
a4454d5
Compare
fe32a5e
to
b177b1e
Compare
5b21d71
to
caf6b19
Compare
b177b1e
to
be93172
Compare
639636f
to
19dbf7d
Compare
0bdf9f1
to
f6f1bd3
Compare
89d5d57
to
064d57f
Compare
# [20] CrateDB patch end. | ||
|
||
""" | ||
# TODO: Complete SA20 migration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this TODO get addressed with this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi. Thanks for spotting this leftover comment. I've spent another day on it, in order to mangle the parameter data into a shape that would be accepted by the new cast
function, but wasn't able to make a cut.
So, I've just created GH-508 in order to track this issue, and eventually resolve it on behalf of a subsequent iteration, and to unblock this patch. Any help on this topic is very welcome.
# | ||
# sqlalchemy.exc.CompileError: Unconsumed column names: characters_name | ||
# | ||
# TODO: Investigate why this is actually happening and eventually mitigate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an issue we are carrying over since the initial implementation of the CrateDB SQLAlchemy dialect. I've also tried to remedy it a few times, but did not manage to improve it yet.
At least, I've created GH-509 now, in order to highlight this spot more prominently. I'd also recommend to investigate it on behalf on a subsequent iteration, in order not to block this patch. Any help on this will be well received.
This comment was marked as outdated.
This comment was marked as outdated.
References: - `sqlalchemy.sql.compiler.SQLCompiler.visit_update` - `sqlalchemy.sql.crud._get_crud_params` Vendored from SQLAlchemy 2.0.0b4, released on Dec 6, 2022.
This effectively concludes the support for SQLAlchemy 2.0, by implementing the same strategy as for the previous versions: After vendoring the vanilla dialect's compiler's `visit_update` and `_get_crud_params` methods, they are patched at a few spots to accommodate CrateDB's features. The changed behavior is mostly for running update statements on nested `OBJECT` or `ARRAY` data types.
Currently, this is 2.0.0b4.
Apparently, `PGCompiler` does not have a specific implementation for `returning_clause`, starting with SA20. On the other hand, the generic implementation changed its method signature, that's why CodeQL would croak otherwise.
bootstrap.sh
Outdated
@@ -70,7 +70,7 @@ function setup_package() { | |||
if [ "${SQLALCHEMY_VERSION}" = "latest" ]; then | |||
pip install "sqlalchemy" --upgrade | |||
else | |||
pip install "sqlalchemy==${SQLALCHEMY_VERSION}" | |||
pip install "sqlalchemy==${SQLALCHEMY_VERSION}" --pre |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the --pre
still required?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for spotting. I don't think so, so I've updated 71a7f0a correspondingly.
@@ -25,3 +25,4 @@ | |||
SA_VERSION = V(sa.__version__) | |||
|
|||
SA_1_4 = V('1.4.0b1') | |||
SA_2_0 = V('2.0.0b1') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SA_2_0 = V('2.0.0b1') | |
SA_2_0 = V('2.0.0') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks. See also 71a7f0a.
Based on #485 and #498, this patch concludes compatibility work with SQLAlchemy 2.0 12 (GH-465) 🎉.
Footnotes
https://docs.sqlalchemy.org/en/20/changelog/whatsnew_20.html ↩
https://docs.sqlalchemy.org/en/20/changelog/migration_20.html ↩