Changes between Version 57 and Version 58 of MySqlDb

Timestamp:

Apr 4, 2011, 7:29:57 PM (13 years ago)

Author:

Thijs Triemstra

Comment:

cosmetic update

MySqlDb

@@ -2 +2 @@
 = MySQL and its MySQLdb Python bindings =
 
-Trac supports the MySQL database backend, provided you comply with the basic requirements exposed below.
+Trac supports the [http://mysql.com MySQL] database backend, provided you comply with the basic requirements exposed below.
 There are also a couple of [#KnownIssues] and supporting this database has proven
 to be painful at times. 
@@ -84 +84 @@
 See http://cheeseshop.python.org/pypi/MySQL-python/1.2.2, which contains links to the .tar.gz source distribution as well as pre-built Windows eggs, but for Python 2.5 only as of this writing. Python 2.6 binaries for windows can be found [http://www.codegood.com/archives/4 here] (unofficial site).
 
-Older versions can be found at the [https://sourceforge.net/projects/mysql-python/ mysql-python] sourceforge project:
- - MySQL-python 1.2.1_p2 was the previously recommended version
- - MySQL-python 1.2.0-3.2.2, MySQL-python 1.2.2b2) were reported to have issues (see #3645).  
- - MySQL-python-1.2.2b2 was [googlegroups:trac-users:e291b3ecb4a990a1 reported] to solve an `AttributeError: 'array.array' object has no attribute 'startswith'` error seen when viewing a changeset... These problems ought to be fixed in 1.2.2b3; if they are not, or if you have other issues, please file a bug in the [https://sourceforge.net/tracker/?group_id=22307&atid=374932 MySQL-python Bug Tracker].
- - ''NOTE: '' On FreeBSD this package is called py-MySQLdb (in ports)
+Older versions can be found at the [https://sourceforge.net/projects/mysql-python/ mysql-python] Sourceforge project:
+|| '''Version''' || '''Notes''' ||
+|| `MySQL-python 1.2.1_p2` || This was the previously recommended version ||
+|| `MySQL-python 1.2.0-3.2.2`, `MySQL-python 1.2.2b2` || Reported to have issues (see #3645) || 
+|| `MySQL-python-1.2.2b2` ||  Was [googlegroups:trac-users:e291b3ecb4a990a1 reported] to solve an `AttributeError: 'array.array' object has no attribute 'startswith'` error seen when viewing a changeset. These problems ought to be fixed in 1.2.2b3; if they are not, or if you have other issues, please file a bug in the [https://sourceforge.net/tracker/?group_id=22307&atid=374932 MySQL-python Bug Tracker] ||
 
-If you are using ActiveState Python 2.6 on Window, you can install with '''"pypm install mysql-python"'''.
+On FreeBSD this package is called {{{py-MySQLdb}}} (in ports).
+
+If you are using ActiveState Python 2.6 on Window, you can install with {{{pypm install mysql-python}}}.
 
 ==== thread-safety is important ====
 You should make sure that you're using a thread-safe version of the bindings.
-To verify this, you can check the ''System Information'' section in the ''About Trac'' page, when you are logged with a user having the CONFIG_VIEW or the TRAC_ADMIN permission. 
+To verify this, you can check the ''System Information'' section in the ''About Trac'' page, when you are logged with a user having the `CONFIG_VIEW` or the `TRAC_ADMIN` permission. 
 You should see a line reading: '''MySQL''' `server: "...", client: "...", thread-safe: 1`. 
 If you're seeing `thread-safe: 0` instead, the MySQL-python version you're using was not correctly built. Check the following resources to see what you should do:
@@ -100 +102 @@
  - [http://mysql-python.svn.sourceforge.net/viewvc/mysql-python/tags/MySQLdb-1.2.2/MySQLdb/site.cfg?revision=499&view=raw MySQLdb-1.2.2/MySQLdb/site.cfg]
 
-Note that even if you build MySQLdb to use the thread-safe libraries, ''About Trac'' may still report that it is not thread-safe. If that happens, verify that it is thread-safe by calling MySQLdb.thread_safe() from a standalone Python script (i.e., not under apache). If the stand-alone test reports that MySQLdb is indeed thread-safe, then the problem may lie with the PHP module. For example, the Red Hat rpm for PHP is built to use the non-thread-safe MySQL libraries, and the apache PHP module apparently gets loaded first. So when python and MySQLdb load, they end up using the already loaded MySQL libraries, which are not thread-safe. The circumvention for this problem is to replace the non-thread-safe libs in /usr/lib/mysql with soft links, so as to have the non-thread-safe lib names point to the thread-safe libs; restart apache, and now Trac should be running in thread-safe mode. 
+Note that even if you build MySQLdb to use the thread-safe libraries, ''About Trac'' may still report that it is not thread-safe. If that happens, verify that it is thread-safe by calling `MySQLdb.thread_safe()` from a standalone Python script (i.e., not under Apache). If the stand-alone test reports that MySQLdb is indeed thread-safe, then the problem may lie with the PHP module. For example, the Red Hat rpm for PHP is built to use the non-thread-safe MySQL libraries, and the Apache PHP module apparently gets loaded first. So when Python and MySQLdb load, they end up using the already loaded MySQL libraries, which are not thread-safe. The circumvention for this problem is to replace the non-thread-safe libs in `/usr/lib/mysql` with soft links, so as to have the non-thread-safe lib names point to the thread-safe libs; restart Apache, and now Trac should be running in thread-safe mode. 
 
 == Conversion Procedures == #Conversion
@@ -116 +118 @@
 
 ==== Collation from "whatever" to "utf8_bin" ====
-First modify DB collation to ensure new tables will be created properly:
+First modify the DB collation to ensure new tables will be created properly:
 {{{
 ALTER DATABASE `trac_database` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
 }}}
 
-Then modify collation for tables. The command below changes default collation for new columns and converts old columns as well. Issue it for every table:
+Then modify the collation for tables. The command below changes the default collation for new columns and converts old columns as well. Issue the command for every table:
 {{{
 ALTER TABLE `table_name` CONVERT TO CHARACTER SET utf8 COLLATE utf8_bin;
@@ -135 +137 @@
 
 === Typical Problems ===
-If you have some strange issues (typically `OperationalError: (2006, 'MySQL server has gone away')`, as in #3645, and your web frontend is Apache, you might have conflicting mysql libraries. Be sure to read: [mod-wsgi:ApplicationIssues#MySQL_Shared_Library_Conflicts]. Another possibility is that you've hit MySQL bug 36639, as explained in ticket:3645#comment:48.
+If you have some strange issues (typically `OperationalError: (2006, 'MySQL server has gone away')`, as in #3645, and your web frontend is Apache, you might have conflicting MySQL libraries. Be sure to read: [mod-wsgi:ApplicationIssues#MySQL_Shared_Library_Conflicts]. Another possibility is that you've hit MySQL bug 36639, as explained in ticket:3645#comment:48.
 
 When changing collation to ''utf8'' MySQL may fail in 4.1.x and 5.0.x versions on MyISAM table type. It will complain about "too big" indexes in some Trac tables. This will be (hopefully) addressed in [milestone:0.10.4]. As a workaround it has been [comment:ticket:3659:5 recommended] to use InnoDB tables instead of MyISAM where this limitation is absent.
@@ -145 +147 @@
 
 === Troubleshooting ===
-If you get an error from python when using trac-admin like this:
+If you get an error from Python when using `trac-admin` like this:
 {{{
 OperationalError: (1045, "Access denied for user 'tracuser'@'localhost' (using password: YES)")
 }}}
 There are a few possibilities:
- 1. Try first to login on the command-line using the user tracuser (mysql -p -h localhost -u tracuser)
- 1. Created user is not yet used by MySQL (Login to the MySQL server(as root): mysql -p and type FLUSH PRIVILEGES;)
- 1. The user is added but the host does not match in the mysql user table (I had this on my FreeBSD setup). mysql -p; use mysql; UPDATE user SET Host="localhost" WHERE User="tracuser"; FLUSH PRIVILEGES;)
+ 1. Try first to login on the command-line using the user `tracuser` (`mysql -p -h localhost -u tracuser`)
+ 1. Created user is not yet used by MySQL (Login to the MySQL server (as root) with`mysql -p` and type: `FLUSH PRIVILEGES;`)
+ 1. The user is added but the host does not match in the MySQL user table (occurred on a FreeBSD setup). Correct this with: `mysql -p; use mysql; UPDATE user SET Host="localhost" WHERE User="tracuser"; FLUSH PRIVILEGES;`