Closed naresh-kumar-by closed 1 year ago
@tkilias at BlueYonder (formerly known as JDA), we are working on a fix and adding support for new sqlalchemy version, we might require additional help.
Consider dropping support for Python 2.7 with a new release that supports SQLAlchemy 1.4. This would fix https://github.com/blue-yonder/sqlalchemy_exasol/issues/93.
I'm also encountering this issue
Has there been any development on this? I'm also facing this issue.
Started the migration to SQLA 1.4.
Updating the dependency itself worked out of the box (no dependency conflicts)
The plugin functionality itself is partially broken
[fixed] The issue reported by @naresh-kumar-by have been fixed ("bug in pre_exec")
[fixed] Failing tests due to usage of deprecated API
[postponed] caching was disabled, to not further complicate the migration see also #190
[in progress] Custom merge "statement" is crashing [in progress]
[pending] Failing unit tests with new SQLA 1.4 tests suite
turbodbc 219 Failing 774 Test: 219 🚫, 310 🟡, 245 :heavy_check_mark:
pyodbc 229 Failing 774 Test: 229 🚫, 302 🟡, 243 :heavy_check_mark:
For more details see also PR #191
After investigating various aspects of the failing custom merge statement, we concluded that a more thorough rewrite, also considering the "new" api concept of SQLA, is the right way to address this issue. Still beforehand we want to make sure the general functionality of the plugin is working with SQLA version 1.4. Therefore first we will focus on addressing the more general issues caused by the SQLA upgrade.
So far 4 major categories of failing tests have been identified:
New tests which have been introduced in SQLA 1.4
Existing tests whose skip condition does to work anymore
Existing tests which fail since the sqla version was updated
Others
While fixing individual tests it became apparent that the majority of the not working tests is rather crashing than failing. Due to the fact that a lot of the crashing tests looked like they have a similar and non api change related cause, I started investigating various of this crashes.
What I have found so far?
Some test(s) which potentially would be skipped fail/crash with an error, because the general test setup crashes (pre skipping the test)
Only Exasol & SQLAalchemy tests which make use of the testing.fixtures.TablesTest
functionality for creating and cleaning up Tables + Data for testing seem to be affected
(:warning: Not validated for all tests yet, just for the once I have investigated so far)
Not all tables/schemas seem to be cleaned up after their associated test(s) have been run
Common Error Messages:
OBJECT_NAME
not foundOBJECT_NAME
already existsAssumptions
testing.fixtures.TablesTest
has changed63 :no_entry_sign: failed, 251 :heavy_check_mark: passed , 321 :yellow_circle: skipped, 144 :boom: errors
76 :no_entry_sign: failed, 255 :heavy_check_mark: passed , 335 :yellow_circle: skipped, 120 :boom: errors
:warning: Finding and fixing the cause(s) of the crashing tests will be the main focus, before continuing with the failing tests :warning:
Further investigation's have shown that the basic SQLA test suite mostly is intact after the upgrade to 1.4
(14 failures), when run in "isolation". Various exasol specific test suites:
seem to have negative side effects which cause 100+ tests to :boom: fail/crash, if run after those test suites. This further strengthens the case for the assumptions mentioned in the previous update:
testing.fixtures.TablesTest
has changedAlso, this narrows down the potential root cause(s).
Common to all those test suites to be that they add/remove schemas.
For test/test_regression.py
it have been proven that the schema manipulating test (TranslateMap
) causes some negative side effect on following test suits.
Further analysis has shown that the majority of the crashing tests was caused, due to implicit schema changes which have been a "side effect" of integration tests added by exasol.
In order to address this, the test setup/execution have been adjusted. Also further improvements regarding test robustness have been identified and are track in #209.
A first set of changes which addresses various issues to support SQLA 1.4 have been merged into the the development branch (dev-sqla-1.4
).
A first superficial analysis of the remaining failing and crashing tests has shown the following:
The remaining crashing tests seem to stem from a behavioral change of sqla, so that the pyodbc based dialect now uses an additional connection for the reflection. This causes tests using the AssertionPool
to crash.
There are no obvious low hanging fruit's to fix
A couple of the failing tests show signs that indicate, SQLA has changed how it is using/interacting with the DDL compiler of the dialect(s). Such indications are:
test.integration.sqlalchemy.test_suite.LongNameBlowoutTest_exasol
turbodbc 9 :no_entry_sign: failed, 189 :heavy_check_mark: passed , 23 :yellow_circle: skipped, 0 :boom: errors
:spiral_notepad: nine of the failing exasol tests within turbodbc
and pyodbc
are caused by the custom merge statement,
which needs to be rewritten/refactored.
It have been decided by PM, that the support for the custom merge statement, is dropped.
If we will be notified, that someone depends on this feature, we are open to add it again.
Hi @Nicoretti , we are using sqlalchemy-exasol at my current company. We still need to evaluate if we're using custom merge statements within our code base. What's the ETA for giving feedback on this?
Also, one more question: I see that the 1.4 branch drops support for <1.4. Will a version which supports <1.4 continue to be maintained, or will this project stop supporting <1.4 altogether once this effort completes?
Thanks!
Hi @jcharlytown,
We still need to evaluate if we're using custom merge statements within our code base. What's the ETA for giving feedback on this?
Take your time, the changes will be published as major
release, if your dependency is pinned to stay on a specific
major version you will be good.
:spiral_notepad: Side note: If the Merge
statement is added again it's very likely that we need to change the API (usage/syntaxt) of it.
Regarding your second question
Also, one more question: I see that the 1.4 branch drops support for <1.4. Will a version which supports <1.4 continue to be maintained, or will this project stop supporting <1.4 altogether once this effort completes?
In order to answer this in more detail, I will need to consult our project management about it. (I'll try to come back to you with an answer, as soon as possible)
best Nico
Hi @jcharlytown,
I had a brief discussion with our project management, and we concluded not to maintain two lines.
If something unforeseen and critical regarding the version(s) supporting SQLA 1.3 would surface, we still would be able to address this if needed.
:information_source: That said, we still advice to update to a version supporting SQLA 1.4
in the near future. :information_source:
SQLA 1.3 is a legacy version
Release: 1.3.24 legacy version | Release Date: March 30, 2021
sqlalchemy-exasol 2.2.0 have been around for more than 2 years and we only had one external bug report in the last year.
sqlalchemy-exasol 2.2.0 - 3.2.2 (all supporting SQLA 1.3) still can be used
best Nico
See also https://github.com/exasol/sqlalchemy-exasol/discussions/250
sqlalchemy_exasol python package is not compatible with new version of sqlalchemy 1.4+ when used with turbodbc dialect. Below is the code to reproduce this issue.