oceanbase / oceanbase/pyseekdb

Make embedded SeekDB compatible with SQLAlchemy table-existence checks

Open
#242 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
62
Forks
35
Avg merge
2d 11h
Merged PRs (30d)
2

Description

Context

langchain-oceanbase CI exposed a SQLAlchemy compatibility issue in the embedded SeekDB path while testing pylibseekdb 1.3.0.post2, pyseekdb 1.4.0, and pyobvector 0.2.28.

SQLAlchemy creates tables with checkfirst=True. For the MySQL dialect this triggers a table-existence probe such as:

DESCRIBE `test`.`some_table`

For MySQL-compatible DB-API drivers, a missing table raises an error with code 1146, SQLAlchemy recognizes it, and has_table() returns False so table creation can continue.

In embedded mode, the missing-table probe propagated as a fatal native exception instead:

pylibseekdb.pylibseekdb.SeekdbError: Table `test.some_table` does not exist failed: code=1146
Observed call path
SQLAlchemy table.create(..., checkfirst=True)
  -> MySQLDialect.has_table()
  -> DESCRIBE `test`.`some_table`
  -> pyobvector embedded DBAPI shim
  -> pyseekdb.client.client_seekdb_embedded.SeekdbEmbeddedClient._execute_query_with_cursor
  -> pylibseekdb cursor.execute
  -> pylibseekdb SeekdbError(code=1146)
Problem

The embedded pyseekdb path needs a SQLAlchemy-compatible adapter behavior for expected table-existence probes.

A missing table during SQLAlchemy has_table() / checkfirst=True should not escape as a fatal runtime failure. It should be translated into the behavior SQLAlchemy expects from a MySQL-compatible driver so table creation can proceed.

Expected behavior

When used through SQLAlchemy-style adapters:

  • missing-table probes with code 1146 are interpreted as has_table() == False;
  • table creation with checkfirst=True continues normally when the table is absent;
  • unexpected embedded database errors still propagate normally;
  • the mapping should use structured error information from pylibseekdb when available, not message-string matching where avoidable.
Possible approaches
  1. Provide a SQLAlchemy-compatible embedded adapter/dialect in pyseekdb that knows how to map embedded SeekDB database errors into SQLAlchemy-compatible behavior.
  2. In the existing embedded client path, expose enough structured exception information for downstream adapters such as pyobvector to detect code 1146 reliably.
  3. Document the expected integration contract for SQLAlchemy-style consumers.
Related lower-level issue

The underlying binding should expose DB-API-compatible error semantics and stable error-code access: oceanbase/seekdb-bindings#42

Why this matters

Downstream projects such as pyobvector and langchain-oceanbase rely on SQLAlchemy table creation and reflection. Without a SQLAlchemy-compatible embedded path, normal missing-table probes become fatal failures in embedded mode.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at pyseekdb.client.client_seekdb_embedded.SeekdbEmbeddedClient._execute_query_with_cursor and follow the error from pylibseekdb cursor.execute through the embedded DBAPI path. Reproduce SQLAlchemy's MySQL-dialect DESCRIBE probe via table.create(checkfirst=True), then verify code 1146 is recognized as an absent table while unexpected errors still propagate. Check the related bindings issue for the structured error information contract.

Written by the indexing model from the issue text.

Assessment

Tech stack
python, sqlalchemy
Domain
backend-api-design, databases
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.