trac 1.0beta from github does not upgrade cache table

[anonymous]

I found that while upgrading my existing trac instances from trac 0.12/0.13 to 1.0beta1 the upgrade is flawed in that db27.py will not be executed.

I have here trac instances using a database_version 27. On upgrade, trac will create a copy of the database file (sqlite that is) having a version identifier of 27.

It will then skip db27 and continue with db29.

In order to overcome this problem, one needs to

sqlite3 db/trac.db update system set value=26 where name = 'database_version';

and run trac <env> upgrade again…

Somebody must have "fucked up" the database migration path, as the last upgrade that I did using 0.12/0.13 already increased the database version to 27 and it did not introduce a third column to the cache table.

TIA for fixing this.

[Remy Blank]

Of course, if your database_version is already 27, Trac won't run db27.py. Or was this a typo, and you meant that it skipped db28.py?

[anonymous]

Replying to rblank:

Of course, if your database_version is already 27, Trac won't run db27.py. Or was this a typo, and you meant that it skipped db28.py?

AFAIK there is no db28, just a db29.

And, yes, the db version was already at 27, so it skipped the db27 file. Since the db version was raised by a previous upgrade done using version 0.13, I wonder why that not already introduced the changes to the cache table…

[anonymous]

there is a db28, just found it.

[anonymous]

Just had a look at the repository, the db27.py file was added to 0.13dev a long time ago. I wonder what went wrong here that the db version was increased to 27 without the actual changes being applied.

I think that this might be an error that exists only on my machines and this must not necessarily be an issue that affects other people's trac instances.

Perhaps we should close this then…

[Remy Blank]

Ok, thanks for the feedback. I'm closing this for now, please reopen if you can reproduce the issue.