[FEATURE] Exasol integration

[abdullah094]

• Added integration for the Exasol database.
• Created a new data source for Exasol.
• All unit tests have been run and passed.

[netlify]

👷 Deploy request for niobium-lead-7998 pending review.

Visit the deploys page to approve it

Name	Link
🔨 Latest commit	9383684

[abdullah094]

@cla-bot check

[joshua-stauffer]

Hi @abdullah094, thanks for the PR! I'd like to see a version of this merged, but want to get alignment at the design level first.

An RFC is required for new data sources (see CONTRIBUTING.md), but I realize that our PR template doesn't have that guidance. I'll fix it for the future, and this time we can continue the design discussion here on the PR.

I'd like to see Exasol supported in GX at the same level as Trino, Clickhouse, Teradata, Vertica, etc. The canonical path is for users to setup a SQLDatasource after installing via great_expectations[exasol]. The good news is that this approach will simplify the PR considerably! We can include Exasol in the data source compatibility reference, include install instructions in the docs, and run a core set of expectations against Exasol in CI. If there's sustained community demand, we can revisit adding a ExasolDatasource in the future.

If that approach is sounds ok to you, I'll detail the changes needed to get this PR merged! I also have a question about longer term maintenance: how actively is sqlalchemy-exasol maintained, and is it expected to track new Python and SQLAlchemy releases? I see that it's currently pinned to python >= 3.10, < 3.14, the same as GX. I expect those bounds to move on our side by October -- will sqlalchemy-exasol support python 3.14 by then?

[abdullah094]

Hello and thanks for responding so quickly on this @joshua-stauffer

The canonical path sound like a good idea to start with. I would love for you to share the details to get those done and merge the PR.

sqlalchemy_exasol will eventually be updated to 3.14. Our team works on maintaining our tools regularly. I am not sure that this will be done till October. I don't know how big of an issue this is for you guys. If this is a make or break issue. I can bring this to the table in our next planning session.

[abdullah094]

Update on the sqlalchemy-exasol

python 3.14 support has been implemented and will be launched by the end of this week.

[joshua-stauffer]

hi @abdullah094, thanks for the update! Great to hear that sqlalchemy_exasol is actively maintained. I'm actively working on an improved test harness for Datasources like Exasol, and expect to complete it in the next two weeks. To minimize rework, I suggest we wait until that lands to move forward with this. I can ping you once it's available, and at that point will review this PR with the suggested changes.

[joshua-stauffer]

Hi @abdullah094! Thanks for your patience -- the test harness I mentioned has landed, so we're ready to move this forward.

Thanks for the update on sqlalchemy-exasol Python 3.14 support - I see that sqlalchemy-exasol 7.1.2 is on PyPI with requires-python = ">=3.10,<3.15", as promised. Looks like you’re a step ahead of us!

What changed while you waited

Adding a SQL backend to GX has been significantly simplified. The walkthrough is in tests/integration/data_sources_and_expectations/README.md under “Onboarding a new SQL backend”.

There’s some parallel work in flight, promoting Oracle to the curated tier of SQL data sources: #12085 brings the dialect under test, and #12091 publishes the install path. Its RFC, #12090, gives a good idea of what we’re looking for to accept this contribution.

The design agreement

Just to be explicit, here’s what we agreed to last month:

• Tier: Exasol joins BackendTier.CURATED_SQL — the eight-case curated suite that every curated-tier backend inherits without editing the suite module. Not STANDARD_SQL. SingleStore and Oracle are both curated-only.
• Public API: Exasol is reached through the generic add_sql, so there is no add_exasol and no ExasolDatasource. A dedicated fluent datasource is additive and can follow later if there’s consistent community interest.
• Install surface: pip install 'great_expectations[exasol]', and nothing else.
• CI: one token in the existing marker-tests matrix, not a job of its own. You inherit that job's Python matrix, permissions, and coverage wiring instead of declaring your own.

The net result of the test harness and the reduced public API scope is that this PR should go from ~900 LOC to around ~150.

On the RFC

Per our initial discussion, we’re waiving the RFC requirement since when you posted this PR the requirements weren’t clearly available within the PR template. That’s been fixed - this PR changes files that require an RFC, and will now fail a CI check. You can pass the check by adding either RFC: <link> or No RFC needed: <reason> in the PR description.

What comes out

• great_expectations/datasource/fluent/exasol_datasource.py, and its export in fluent/__init__.py
• great_expectations/compatibility/exasol.py
• tests/datasource/fluent/test_exasol_datasource.py
• the marker-tests-exasol job in ci.yml, all 91 lines of it, and the three job-list entries that reference it
• the --exasol pytest flag, its tests/conftest.py plumbing, and the tests/test_utils.py changes — marker selection replaces all of it
• the sqlalchemy_execution_engine.py change, unless the suite proves it's needed (see below)

What goes in

The declaration. tests/integration/test_utils/data_source_config/exasol.py: an ExasolDatasourceTestConfig(SqlDatasourceTestConfig) decorated with @register_sql_backend, stating a single BACKEND_SPEC = SqlBackendSpec(...), plus an ExasolBatchTestSetup overriding build_connection_string and make_asset. Oracle's file is 132 lines including comments; that's the size to aim for.

The wiring, added by hand in the same change:

• the module's import in data_source_config/__init__.py, before the tiers import (step 4 of the walkthrough explains why the ordering matters)
• pyproject.toml: the exasol marker entry
• tests/conftest.py: exasol added to REQUIRED_MARKERS
• tasks.py: a MARKER_DEPENDENCY_MAP entry naming both the requirements file and the compose service
• .github/workflows/ci.yml: the exasol token in the marker-tests marker matrix
• assets/docker/exasol/docker-compose.yml — you already have this

Split this into three PRs

Cleanest would be to deliver this work in three PRs:

• PR 1 — this one. Driver, container, wiring, backend record, CI token. The exasol key is held in setup.py's ignore_keys: the driver installs for CI, no extra is published, and a test pins the hold so restoring it has to be a deliberate edit rather than a side effect of touching reqs/.
• PR 2 — stacked on PR 1, opened as a draft. Moves exasol out of ignore_keys into the SQLAlchemy-2 pin group and adds the two docs rows. Held until the bar below is met.
• PR 3 - Standalone PR adding Exasol to the GX docs. The docs go live on merge rather than release, so I’ll hold this and merge it concurrently with the release this work ships in.

You can reuse this PR as the first one, if you want - a lot of the substantive changes are already here.

Requirements for release

These are the same requirements that hold for the Oracle extra:

• The curated suite passes without exclusions: value_set_validation, numeric_aggregation, row_count, regex_match, uniqueness, row_condition, unexpected_rows_query, quoted_identifiers.
• Documentation reflects actual support: the install row in _sql_dialect_installation_commands.md, and the data source list in docs/help/compatibility_reference.md.
• No regressions across the full test suite

Review notes on what you've already written

Here’s an early review on this PR, which should help carry it forward into the version we can merge:

• Pin the image. :latest makes the lane irreproducible — Oracle pins a concrete 21c XE tag, and we'd want the same here.
• Let's use a simpler container. exasol/docker-db is a 4.3 GB image that needs privileged: true and a self-signed certificate whose fingerprint you're capturing with openssl at runtime. That's more than the shared marker-tests job can carry — it runs no per-backend steps, so the fingerprint capture has nowhere to live, and privileged mode on a shared runner is a bigger ask than a test lane should be making. exasol/nano looks like the better fit: 0.14 GB, no privileged flag anywhere in its docs, and Exasol publishes a compose file for it (shm_size: 512mb, pids_limit: -1, port 8563). It's still TLS-only with a self-signed cert, so I'd expect to disable verification in the connection string rather than pin a fingerprint — for a throwaway test container that seems fine. Does Nano cover everything the suite needs, or is there something in docker-db we'd lose?
• Trim the driver pins. Can the whole requirements file just be sqlalchemy-exasol? Wondering if the other two deps are pulled in transitively.
• GXSqlDialect.EXASOL and the identifier-quote mapping are core changes, and need evidence. The curated suite's quoted_identifiers case will be the demonstration; could you pull out the mapping to its own commit, so we can easily red-green it and prove that it’s required?

One thing to expect from CI

marker-tests runs on pull_request_target, so the workflow is read from the base branch. The exasol token you add will not produce an Exasol lane on this PR — the lane's first live run happens once it lands. You should be able to run locally to get the feedback you need for development; I’ll manually trigger the CI run to prove that it works prior to merge.

Thanks again for your patience, and thanks for the contribution!