Edgewall Software
Modify

Opened 17 years ago

Closed 14 years ago

#5556 closed defect (cantfix)

server "crash", restart, then cannot view tickets

Reported by: Morten W. Hansen <mortenh@…> 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 Christian Boos)

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)

comment:1 by Christian Boos, 17 years ago

Description: modified (diff)

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.

comment:2 by Christian Boos, 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).

in reply to:  1 ; comment:3 by Emmanuel Blot, 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 ?

in reply to:  3 ; comment:4 by mvanlamz@…, 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!

in reply to:  4 comment:5 by Emmanuel Blot, 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 Christian Boos, 17 years ago

Milestone: 0.10.51.0
Priority: normallow

Optimal MySQL support due at a later time …

comment:7 by Christian Boos, 15 years ago

Milestone: 1.0unscheduled

Milestone 1.0 deleted

comment:8 by Remy Blank, 14 years ago

Milestone: triaging
Resolution: cantfix
Status: newclosed

The original issue was actually an InstallationIssue.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Jonas Borgström.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Jonas Borgström to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.