bug(migrations): quoted version_table renders invalid CREATE TABLE
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 84/100
Research direction
Start in sqlspec/migrations/base.py at BaseMigrationTracker._split_version_table, then inspect _tracking_table_builder and the SyncMigrationTracker example in sqlspec/migrations/tracker.py. Reproduce with the quoted App.Tracker input and postgres DDL; done means CREATE TABLE uses "App"."Tracker" without doubled quotes and the tracker's other statements use the same table.
Written by the indexing model from the issue text.
Description
A quoted migration version_table name produces invalid CREATE TABLE SQL. The quotes around each part are kept, then quoted again when the DDL is rendered.
Reproduce
from sqlspec.migrations.tracker import SyncMigrationTracker
tracker = SyncMigrationTracker('"App"."Tracker"')
print(repr(tracker.version_table_name), repr(tracker.version_table_schema))
# '"Tracker"' '"App"'
print(tracker._tracking_table_ddl().build(dialect="postgres").sql.splitlines()[0])
# CREATE TABLE IF NOT EXISTS """App"""."""Tracker""" (
Expected
CREATE TABLE IF NOT EXISTS "App"."Tracker" (, with the tracker's other statements referring to the same table.
Cause
BaseMigrationTracker._split_version_table (sqlspec/migrations/base.py) splits on the dot but leaves the double quotes on each part. The DDL builder in _tracking_table_builder then treats the quotes as part of the name and escapes them. Any adapter that uses the generic tracker DDL is affected. To fix it, strip the quotes when splitting and keep a flag saying the name was quoted, so the table is still created with its exact case.
- Dominant language
- Python
- Stars
- 102
- Forks
- 9
- Avg merge
- 12h 20m
- Merged PRs (30d)
- 72
Getting set up
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from litestar-org/sqlspec
-
Difficulty 2/5 1-3 hours Newbie friendliness 92/100
litestar-org/sqlspec#816 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 45/100
litestar-org/sqlspec#810 ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 72/100
litestar-org/sqlspec#788 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
litestar-org/sqlspec#728 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
litestar-org/sqlspec#509 ·
Maintainers usually reply within 1 day
All issues in litestar-org/sqlspec
Similar issues
-
docs pydanty:is-working
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
pydantic/pydantic-ai#8863 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
run-llama/llama_index#23278 ·
Maintainers usually reply within 2 days
-
documentation from-review-extraction github-actions priority: low severity:nit
Difficulty 1/5 Under an hour Newbie friendliness 92/100
LearningCircuit/local-deep-research#6946 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
oracle/langchain-oracle#323 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
tenstorrent/tt-metal#58057 · 1 comment ·
Maintainers usually reply within 1 day