[PATCH] 0.12 db-upgrade fix for repo-less installs

[jonas@…]

Doing a trac-admin instance upgrade from 0.11.7 to 0.12dev, raised this error:

    OperationalError: near "%": syntax error

(source:trunk/trac/upgrades/db24.py@9554#L48​)

I know nothing about python, but I hacked around and made a patch that seems to fix the issue. db24.py was expecting to have a repo and failed when no data could be given to the subsequent queries.

This patch just checks if there is any data before running the queries.

[jonas@…]

The patch in question

[Remy Blank]

Good catch, thanks! I'll fix that tomorrow.

[Christian Boos]

You should also tell us which line had the error, as I couldn't reproduce the issue near "%": syntax error. Actually, I didn't have any problem in upgrading an 0.11.7 environment which had no repository defined.

So, which database backend are you using, and which revision of Trac trunk?

Normally, in db23.py we create the repository table and fill it with the default repository, taking repository_dir and youngest_rev from the system table.

A freshly created, repository-less, 0.11.7 db looks like that:

sqlite> select * from system;
database_version|21
initial_database_version|21
youngest_rev|

After an upgrade, I have:

sqlite> select * from repository;
1|name|
1|youngest_rev|

[jonas@…]

I don't have the database by hand right now, but from memory..

Replying to cboos:

You should also tell us which line had the error, as I couldn't reproduce the issue near "%": syntax error. Actually, I didn't have any problem in upgrading an 0.11.7 environment which had no repository defined.

Actually, my system has lived trough multiple updates, so it's entirely possible that it's a combination of updates that gives that result. I will look tomorrow which line was failing on my backuped instance. By the way, it would have been much easier for me to debug that error if trac-admin had printed the full stack-trace (or provided an option to do so)

So, which database backend are you using, and which revision of Trac trunk?

sqlite3

Normally, in db23.py we create the repository table and fill it with the default repository, taking repository_dir and youngest_rev from the system table.

A freshly created, repository-less, 0.11.7 db looks like that:

sqlite> select * from system;
database_version|21
initial_database_version|21
youngest_rev|

After an upgrade, I have:

sqlite> select * from repository;
1|name|
1|youngest_rev|

Okay, I'll give you these details tomorrow

[Remy Blank]

Replying to jonas@…:

By the way, it would have been much easier for me to debug that error if trac-admin had printed the full stack-trace (or provided an option to do so)

The full backtrace should be in the log.

sqlite3

Could you please also provide the version of:

• the SQLite database library
• the SQLite Python bindings
• the trunk revision that you are using

[jonas@…]

Additional infos:

sqlite> select * from system;
database_version|21

• libsqlite3-0 3.6.16-1ubuntu1
• python-pysqlite2 2.5.5-1ubuntu1
• Trac: 0.12dev r9554

[jonas@…]

The debug log with stack-trace

[Christian Boos]

added line number info from the backtrace

[Remy Blank]

I can indeed reproduce the issue if id_name_list is [] in db24.py. Working on a fix…

[Remy Blank]

Handle args=[] correctly in Cursor.executemany().

[Remy Blank]

I don't understand why the args argument to Cursor.executemany() is optional. It isn't in the DB-API, and it doesn't make sense anyway. Handling the case where args=[] correctly, as in the patch above, fixes the issue. Feedback welcome.

[Christian Boos]

Patch looks good, and I run the tests on the 3 backends with no issues.

[Remy Blank]

Thanks for testing. Patch applied in [9571].