-
Notifications
You must be signed in to change notification settings - Fork 95
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
Remove unused import for SQLAlchemy 2 compatibility #128
Remove unused import for SQLAlchemy 2 compatibility #128
Conversation
Thanks for doing the research on this! Of course this is an easy merge. Did you have any issues installing with SQLAlchemy==2.x given that we're pinned to ^1.x right now? I thought that if we merge this it will still fail on install because of the dependency specification in |
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.
Change LGTM just wondering if we should update pyproject.toml for this as well. Even experimentally as a .dev
release?
Like you inferred, installing does fail for us. We're largely experimenting right now so we're working off my fork where I bumped SQLAlchemy to ^2.0 and Pandas to ^2.0. An official or For the record all unit tests pass when run with the upgraded deps (as long as |
Signed-off-by: William Gentry <william.barr.gentry@gmail.com>
Signed-off-by: Jesse Whitehouse <jesse.whitehouse@databricks.com>
5f47f67
to
8cfd6f8
Compare
Sorry to leave this hanging so long. I confirmed the tests pass and am preparing to merge. I'll cut you a dev release with the SQLAlchemy version relaxed to include sqlalchemy>=2.0 -- I suspect we have more changes needed to properly support sqla v2 but this will be a start. |
I've forked I note that most of our e2e tests fail because |
Signed-off-by: William Gentry <william.barr.gentry@gmail.com> Signed-off-by: Jesse Whitehouse <jesse.whitehouse@databricks.com> Co-authored-by: Jesse Whitehouse <jesse.whitehouse@databricks.com>
This PR removes an unused import that was preventing the
databricks-sql-python
module from being compatible with SQLAlchemy 2.In our company's project, we have fully migrated to SQLAlchemy 2.0.4. However, the current
databricks-sql-python
module obviously requires SQLAlchemy >=1.3.0. Despite this, I found that by simply removing a single unused import, the module could be effectively used in our SQLAlchemy 2.0.4 project.I ran the unit tests before and after removing the import. In both cases, the results were identical with 92 tests passed and 2 skipped. This makes sense since the imported
processors
object was never used anywhere.While the ideal solution would be to update the entire project to be compatible with SQLAlchemy 2.0, this smaller change allows users to integrate
databricks-sql-python
into their SQLAlchemy 2 projects without any immediate breaking issues, if they're willing to use the connector out-of-spec. This serves as a temporary workaround for those users until a full migration to SQLAlchemy 2 can be achieved (I'm happy to help with that)