Alembic Version Number

[BrokenEagle]

Current situation

The alembic_version table structure is hardcoded (even though the name can be changed), meaning that using Alembic for migrations will always create a table that does nothing else but store a single value.

Use case

Store the version number in a multiple use table such as the following.

CREATE TABLE version (
	id TEXT NOT NULL, 
	ver_num TEXT NOT NULL, 
	CONSTRAINT pk_version PRIMARY KEY (id)
) WITHOUT ROWID;
INSERT INTO version VALUES
("alembic_version",  "c3ee584288f0");
SELECT version.ver_num
FROM version
WHERE version.id = "alembic_version";

Proposed solution

Recoding to use something like the above would probably be too much, plus it removes the flexibility for the user to store that value however they may wish to. Providing getter/setter hooks that the user can set would facilitate the ability to do something like this. With this, Alembic would call your supplied functions to get the current version number and to set any different values. The implementation of those functions would be completely left up to the user. When those hooks are NULL, Alembic would use the current set of functions it uses as the default case.

[zzzeek]

Current situation

The alembic_version table structure is hardcoded (even though the name can be changed), meaning that using Alembic for migrations will always create a table that does nothing else but store a single value.

this is not correct. the alembic_version table stores multiple rows as it supports multiple branch points.

Use case

Store the version number in a multiple use table such as the following.

CREATE TABLE version (
	id TEXT NOT NULL, 
	ver_num TEXT NOT NULL, 
	CONSTRAINT pk_version PRIMARY KEY (id)
) WITHOUT ROWID;
INSERT INTO version VALUES
("alembic_version",  "c3ee584288f0");
SELECT version.ver_num
FROM version
WHERE version.id = "alembic_version";

that looks like...an implementation? what task are you wishing to solve with Alembic which it can't do right now? (that would be a use case)

Proposed solution

Recoding to use something like the above would probably be too much, plus it removes the flexibility for the user to store that value however they may wish to. Providing getter/setter hooks that the user can set would facilitate the ability to do something like this. With this, Alembic would call your supplied functions to get the current version number and to set any different values. The implementation of those functions would be completely left up to the user. When those hooks are NULL, Alembic would use the current set of functions it uses as the default case.

users should not store things in the alembic_version table and there is no reason to do so.

overall I am not detecting here what problem needs to be solved, unless it is some kind of cosmetic concern about alembic having a table in the database (not sufficient reason to change things)

[BrokenEagle]

...unless it is some kind of cosmetic concern about alembic having a table in the database...

Mostly this. I was wanting to combine all version numbers for a database, including both the table structure (alembic version) as well as the underlying values (data version(s)). I suspected that it may be a no-go due to the narrow use case, but I wanted to at least get the idea out there. Thanks for the quick reply.