Opened 17 years ago
Closed 14 years ago
#5556 closed defect (cantfix)
server "crash", restart, then cannot view tickets
Reported by: | Owned by: | Jonas Borgström | |
---|---|---|---|
Priority: | low | Milestone: | |
Component: | general | Version: | |
Severity: | normal | Keywords: | mysql |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description (last modified by )
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'")
Attachments (0)
Change History (8)
follow-up: 3 comment:1 by , 17 years ago
Description: | modified (diff) |
---|
comment:2 by , 17 years ago
Keywords: | mysql added |
---|---|
Milestone: | → 0.10.5 |
That being said, make sure that your database use the correct encoding on every table (see the MySqlDb page).
follow-up: 4 comment:3 by , 17 years ago
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 ?
follow-up: 5 comment:4 by , 17 years ago
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!
comment:5 by , 17 years ago
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.
comment:6 by , 17 years ago
Milestone: | 0.10.5 → 1.0 |
---|---|
Priority: | normal → low |
Optimal MySQL support due at a later time …
comment:8 by , 14 years ago
Milestone: | triaging |
---|---|
Resolution: | → cantfix |
Status: | new → closed |
The original issue was actually an InstallationIssue.
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.