server "crash", restart, then cannot view tickets

[Morten W. Hansen <mortenh@…>]

The trac server stopped working yesterday. We couldn't access our trac system and then restarted the server. However, now trying to view the tickets produces this (it is the same result for all active tickets):

Oops…
Trac detected an internal error:

If you think this really should work and you can reproduce it, you should consider reporting this problem to the Trac team.

Go to http://trac.edgewall.org/ and create a new ticket where you describe the problem, how to reproduce it. Don't forget to include the Python traceback found below.

TracGuide — The Trac User and Administration Guide 

Python Traceback

Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 406, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 237, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/lib/python2.3/site-packages/trac/ticket/web_ui.py", line 313, in process_request
    get_reporter_id(req, 'author'))
  File "/usr/lib/python2.3/site-packages/trac/ticket/web_ui.py", line 630, in _insert_ticket_data
    for change in self.grouped_changelog_entries(ticket, db):
  File "/usr/lib/python2.3/site-packages/trac/ticket/web_ui.py", line 677, in grouped_changelog_entries
    changelog = ticket.get_changelog(when=when, db=db)
  File "/usr/lib/python2.3/site-packages/trac/ticket/model.py", line 296, in get_changelog
    "ORDER BY time", (self.id,  str(self.id), self.id))
  File "/usr/lib/python2.3/site-packages/trac/db/util.py", line 50, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
  File "/usr/lib/python2.3/site-packages/trac/db/util.py", line 50, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
  File "build/bdist.linux-x86_64/egg/MySQLdb/cursors.py", line 166, in execute
  File "build/bdist.linux-x86_64/egg/MySQLdb/connections.py", line 35, in defaulterrorhandler
OperationalError: (1267, "Illegal mix of collations (latin1_swedish_ci,IMPLICIT) and (utf8_general_ci,COERCIBLE) for operation 'UNION'")

[cboos]

Well, I begin to wonder if we shouldn't begin to deprecate the MySQL support.

So far, I only took care of this buggy backend because nobody else did, and I'm not that interested in involving more time in this than I already had.

So if nobody steps up to maintain the MySQL backend, I think we should simply flag it as unsupported.

[cboos]

That being said, make sure that your database use the correct encoding on every table (see the MySqlDb page).

[eblot]

Replying to cboos:

Well, I begin to wonder if we shouldn't begin to deprecate the MySQL support.

IMHO, I think we should have deprecated it a long time ago (I never expressed this opinion as I'm sure it can trigger some strong arguments...), knowing the energy and time it takes for a very few benefits.

Many people simply want to use MySQL simply because they already have a MySQL server up and running, and they fear installing another DB engine. However SQLite is enough for many cases, and require virtually no setup. For larger projects, PostgreSQL would fit.

So if nobody steps up to maintain the MySQL backend, I think we should simply flag it as unsupported.

+1.
Could it be converted to a plugin ?

[mvanlamz@…]

Replying to eblot:

Replying to cboos:

Well, I begin to wonder if we shouldn't begin to deprecate the MySQL support.

IMHO, I think we should have deprecated it a long time ago (I never expressed this opinion as I'm sure it can trigger some strong arguments...), knowing the energy and time it takes for a very few benefits.

Many people simply want to use MySQL simply because they already have a MySQL server up and running, and they fear installing another DB engine. However SQLite is enough for many cases, and require virtually no setup. For larger projects, PostgreSQL would fit.

Deprecating support for MySQL would ultimately lead to fewer installations of trac. Where I work, there's no chance of getting PostgreSQL on the server any time soon, so without MySQL support, we'd have to abandon trac. In general, it's good to keep your software database-neutral, so that your fortunes won't simply rise and fall with the popularity of your chosen database.

And for what it's worth, I personally appreciate the work that goes into MySQL support. Thanks!

[eblot]

Replying to mvanlamz@gmail.com:

Deprecating support for MySQL would ultimately lead to fewer installations of trac. Where I work, there's no chance of getting PostgreSQL on the server any time soon, so without MySQL support, we'd have to abandon trac.

Do you really have more than 10 requests a second on your Trac installation ?

OTOH, the more time spent trying to fix the various and numerous MySQL issues, or even dealing with MySQL tickets the less time dedicated to develop other features (or to fix other bugs) in Trac. I can't tell the exact ratio between PostgreSQL and MySQL -originated tickets, but I'm pretty sure it is not balanced.

In general, it's good to keep your software database-neutral

Agreed. The trouble is the experience shows that up to now, support for the DB back-end is far from being neutral.

[cboos]

Optimal MySQL support due at a later time ...

[cboos]

Milestone 1.0 deleted

[rblank]

The original issue was actually an InstallationIssue.