db_default.py generates some bogus tables

[outi <outi@…>]

I tried to get the post-commit script to work, but failed. So i took a closer look at the script and it's sql-queries. During doing so i realised that the database layout of 2 tables was different than it supposed to be. The problem with db_default.py are the comments placed in the structure of table layout. On my Systems (all FreeBSD 5.3-Stable and SQLlite 2.8.16) the generated tables have some bogus columns and are missing some other. Very stange is that trac keeps working! Only post-commit hook fails. Maybe there are some functions that suffer from this bug, but i didn't trigger them yet.

Table "ticket" with comments in file:

Column	Type
id	integer PRIMARY KEY
time	integer
--	problem description (long) keywords text
component	text
severity	text
priority	text
owner	text
cc	text
resolution	text
summary	text

Table "ticket" without comments:

Column	Type
id	integer PRIMARY KEY
time	integer
changetime	integer
component	text
severity	text
priority	text
owner	text
reporter	text
cc	text
url	text
version	text
milestone	text
status	text
resolution	text
summary	text
description	text
keywords	text

Tables "permission" and since some revisions "node_change", too. I'll attach a patch for this. Hopefully someone can verify this bug.

[outi <outi@…>]

Patch for db_default.py based on Revision 1435

[outi <outi@…>]

reassign to some more "active" person. IMHO this is a blocker or some really weird thing that i want to get solved.

[mrowe]

The patch that you have provided simply removes all comments from the SQL. If this resolves the problem for you, this suggests that the problem is with the SQLite installation that you are using rather than Trac itself. I think it is a safe assumption on Trac's behalf that SQLite will interpret and treat SQL comments appropriately.

Alternately, it could be possible that the db_default.py file that you are using has incorrect line-endings for the operating system that you are using. This could lead to SQLite treating the comment as ending later than when intended.

[cmlenz]

The line ending hint makes sense.

Really, if the SQL comments in db_default.py themselves were really a problem, we'd have noticed long before.

[cmlenz]

Pretty sure this is invalid, see previous comments.