Cannot run migration when using timestamp version numbers

Bug #1512561 reported by Andrew
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
sqlalchemy-migrate
In Progress
Undecided
Andrew

Bug Description

The changeset method in migrate/versioning/repository.py (around line 200), does not work for timestamped version numbers. The list comprehension which determines the set of versions between :start: and :end: assumes that the versions are 1 apart from each other. This is obviously wrong (most of the time) when using timestamped version numbers, resulting in the following traceback:

Traceback (most recent call last):
  File "/Users/andrew/work/incubator/hilo-backend/venv/bin/migrate", line 11, in <module>
    sys.exit(main())
  File "/Users/andrew/work/incubator/hilo-backend/venv/lib/python3.4/site-packages/migrate/versioning/shell.py", line 209, in main
    ret = command_func(**kwargs)
  File "/Users/andrew/work/incubator/hilo-backend/venv/lib/python3.4/site-packages/migrate/versioning/api.py", line 186, in upgrade
    return _migrate(url, repository, version, upgrade=True, err=err, **opts)
  File "<decorator-gen-15>", line 2, in _migrate
  File "/Users/andrew/work/incubator/hilo-backend/venv/lib/python3.4/site-packages/migrate/versioning/util/__init__.py", line 160, in with_engine
    return f(*a, **kw)
  File "/Users/andrew/work/incubator/hilo-backend/venv/lib/python3.4/site-packages/migrate/versioning/api.py", line 345, in _migrate
    changeset = schema.changeset(version)
  File "/Users/andrew/work/incubator/hilo-backend/venv/lib/python3.4/site-packages/migrate/versioning/schema.py", line 82, in changeset
    changeset = self.repository.changeset(database, start_ver, version)
  File "/Users/andrew/work/incubator/hilo-backend/venv/lib/python3.4/site-packages/migrate/versioning/repository.py", line 225, in changeset
    changes = [self.version(v).script(database, op) for v in versions]
  File "/Users/andrew/work/incubator/hilo-backend/venv/lib/python3.4/site-packages/migrate/versioning/repository.py", line 225, in <listcomp>
    changes = [self.version(v).script(database, op) for v in versions]
  File "/Users/andrew/work/incubator/hilo-backend/venv/lib/python3.4/site-packages/migrate/versioning/repository.py", line 189, in version
    return self.versions.version(*p, **k)
  File "/Users/andrew/work/incubator/hilo-backend/venv/lib/python3.4/site-packages/migrate/versioning/version.py", line 163, in version
    return self.versions[VerNum(vernum)]
KeyError: <VerNum(1)>

Andrew (mason-y)
Changed in sqlalchemy-migrate:
assignee: nobody → Andrew (mason-y)
Revision history for this message
Andrew (mason-y) wrote :

 Closes-Bug: 1512561

This is a quick work-around. The code for sequentially versioned schemas
is left unchanged, but this approach would probably work for those
version numbers as well.

All tests are passing on python 2.x. On python 3.x, there are 4
failures, but none appear related to this change.

Andrew (mason-y)
Changed in sqlalchemy-migrate:
status: New → In Progress
Revision history for this message
Andrew (mason-y) wrote :

Somehow was able to delete my previous patch, but not change it... oh well.

Anyway, I made a mistake with regards to strictness of inequalities for lower/upper bounds for upgrade/downgrade.
Here is the first part of the patch.

Revision history for this message
Andrew (mason-y) wrote :

And here is the second part.

Revision history for this message
Andrew (mason-y) wrote :

fixes the lower bound on downgrades, with the added bonus of simplifying some code

Revision history for this message
Swati (swatisinghi) wrote :

I still see the issue, is the patch not applied to the main branch. I used pip install sqlalchemy-migrate to install the module. Please help.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.