Issue 950410
Created on 2004-05-08 13:07 by gregsf, last changed 2012-10-10 11:48 by admin.
File name |
Uploaded |
Description |
Edit |
Remove |
qj2.tar.gz
|
gregsf,
2004-06-11 17:13
|
Complete tracker to reproduce the problem |
|
|
msg1209 |
Author: [hidden] (gregsf) |
Date: 2004-05-08 13:07 |
|
I can't get 0.7 to run with mysql. Simply upgrading a
tracker with
a mysql backend from 0.6.9 to 0.7 (including adding the
two lines to dbinit.py) resulted in an exception. The
HTML output is shown in the attached file.
I then tried a different strategie: Upgrading with
anydbm backend to 0.7 (works fine so far), then
exporting the tracker, changing the backend to mysql
and re-importing the tracker. This leads to the
following exception from roundup-admin import which is
similar to the other one.
mysql version is 4.0.18 standard
Traceback (most recent call last):
File
"/usr/local/lib/python2.3/site-packages/roundup/admin.py",
line 1281, in run_command
ret = function(args[1:])
File
"/usr/local/lib/python2.3/site-packages/roundup/admin.py",
line 1122, in do_import
cl.import_journals(reader)
File
"/usr/local/lib/python2.3/site-packages/roundup/backends/rdbms_common.py",
line 2436, in import_journals
self.db.setjournal(self.classname, nodeid, l)
File
"/usr/local/lib/python2.3/site-packages/roundup/backends/rdbms_common.py",
line 1019, in setjournal
journaltag, action, params)
File
"/usr/local/lib/python2.3/site-packages/roundup/backends/rdbms_common.py",
line 1067, in save_journal
self.cursor.execute(sql, entry)
File
"/usr/lib/python2.3/site-packages/MySQLdb/cursors.py",
line 95, in execute
return self._execute(query, args)
File
"/usr/lib/python2.3/site-packages/MySQLdb/cursors.py",
line 114, in _execute
self.errorhandler(self, exc, value)
File
"/usr/lib/python2.3/site-packages/MySQLdb/connections.py",
line 33, in defaulterrorhandler
raise errorclass, errorvalue
RuntimeError: maximum recursion depth exceeded
|
msg1210 |
Author: [hidden] (richard) |
Date: 2004-05-10 00:20 |
|
Logged In: YES
user_id=6405
Would you be able to supply the export that causes the error?
Email it to me privately (richard at mechanicalcat.net) if you
don't want to make it public.
|
msg1211 |
Author: [hidden] (richard) |
Date: 2004-05-10 01:27 |
|
Logged In: YES
user_id=6405
I believe I've fixed this in CVS.
|
msg1212 |
Author: [hidden] (richard) |
Date: 2004-05-12 09:30 |
|
Logged In: YES
user_id=6405
Could you give 0.7.1 a try please? I believe it fixes your
problem.
|
msg1213 |
Author: [hidden] (gregsf) |
Date: 2004-05-14 10:47 |
|
Logged In: YES
user_id=915812
I have tried to upgrade to 0.7.1
Unfortunately both problems persist. Additionally, when
upgrading from 0.6.9 to 0.7.1 with anydbm I'm not allowed to
access anything. Perhaps I've messed up my installation by now.
|
msg1214 |
Author: [hidden] (gregsf) |
Date: 2004-05-14 11:03 |
|
Logged In: YES
user_id=915812
Addendum: I just realized I forgot to drop the database before
trying the import this time (definitely not last time with
0.7.0). After recreating the database the import worked with
0.7.1.
I'm still having the permision problem though (which
probably is a different issue and I'll look into it) and
upgrading a mysql_backend fro 0.6.9 directly still doesn't
appear to work.
For completeness sake, here's the permission error message:
Error response
Error code 403.
Message: /qj/ (You are not allowed to view items of class
category).
Error code explanation: 403 = Request forbidden --
authorization will not help.
Note that I did add the required lines to dbinit.py:
for cl in 'priority', 'status':
p = db.security.getPermission('View', cl)
db.security.addPermissionToRole('User', p)
|
msg1215 |
Author: [hidden] (richard) |
Date: 2004-05-15 22:07 |
|
Logged In: YES
user_id=6405
Please make sure you've followed the upgrading
documentation's notes on permissions changes in 0.6 -> 0.7
|
msg1216 |
Author: [hidden] (richard) |
Date: 2004-05-25 00:38 |
|
Logged In: YES
user_id=6405
I'll close this issue in a week if there's no feedback.
|
msg1217 |
Author: [hidden] (gregsf) |
Date: 2004-06-02 18:52 |
|
Logged In: YES
user_id=915812
I tried another round with 0.7.3. it's getting worse :-(
I can upgrade a tracker with an anydb backend from 0.6.9 to
0.7.3 without problem. Afterwards, dumping and restoring
fails, but this is a different issue.
Trying to migrate the tracker to mysql with 0.6.9, then
upgrading to 0.7.3 (including all changes mentioned in
updates.txt) still fails with the original error: maximum
recursion depth exceeded
|
msg1218 |
Author: [hidden] (richard) |
Date: 2004-06-03 06:14 |
|
Logged In: YES
user_id=6405
Just so we're clear: you have a 0.6 database using anydbm
that you've exported, then imported into 0.6 using mysql. Then
upgrading to 0.7 results in the above error?
Would you be willing to make the 0.6 export available to me so
I can debug the problem? Contact me via my sourceforge email
address (richard@users...)
|
msg1219 |
Author: [hidden] (anonymous) |
Date: 2004-06-08 21:28 |
|
Logged In: NO
I am exactlty same error after upgrading tracker from
0.6.9 to 0.7.3. This is same with several trackers, both
started out on mysql. The only changes to vanila mysql
installation was to remove Anonymous access to the
trackers.
|
msg1220 |
Author: [hidden] (alexg2000) |
Date: 2004-06-08 21:35 |
|
Logged In: YES
user_id=1059613
I am same person as nobody in the last note.
richard: if you are not able to reproduce the problem, let
me know, and I can get you a dumps of the broken
trackers.
|
msg1221 |
Author: [hidden] (richard) |
Date: 2004-06-09 06:31 |
|
Logged In: YES
user_id=6405
Please be absolutely clear on the steps you take to reproduce
this problem, as I can't do so here. Indicate:
1. when roundup-admin is invoked, and with what parameters
2. when a software update is invoked using setup.py.
A statement like "upgrading tracker from 0.6.9 to 0.7.3" could
mean any number of actions were taken.
|
msg1222 |
Author: [hidden] (richard) |
Date: 2004-06-09 10:05 |
|
Logged In: YES
user_id=6405
OK, I'm pretty sure I've nailed the recursion exception
now. I'll be releasing 0.7.4 tomorrow some time (it's
getting too late here).
|
msg1223 |
Author: [hidden] (gregsf) |
Date: 2004-06-11 17:13 |
|
Logged In: YES
user_id=915812
Sorry, I'm afraid the problem persists with 0.7.4
Did you get the tracker I sent along with the instructions
how to reproduce the problem? I'll attach it here as well.
The steps are:
Check that the tracker runs with 0.6.11. admin pasword is 'x'
export the tracker, switch to mysql, re-import, check again,
should be fine
upgrade to 0.7.4. When changing roundup versions I'm
removing both /usr/local/share/roundup and
/usr/local/lib/python2.3/site-package-roundup before running
python setup.py install --force
Follow the upgrade steps from upgrading.txt, i.e. add
for cl in 'issue', 'file', 'msg', 'query', 'keyword':
p = db.security.getPermission('View', cl)
db.security.addPermissionToRole('User', p)
p = db.security.getPermission('Edit', cl)
db.security.addPermissionToRole('User', p)
for cl in 'priority', 'status':
p = db.security.getPermission('View', cl)
db.security.addPermissionToRole('User', p)
db.security.addPermissionToRole('Anonymous', p)
to dbinit.py and DEFAULT_TIMEZONE to config.py
Start the tracker (I'm using roundup-server) and try to view
a page or run roundup-admin to export the tracker. Both
leads to the recursion exception.
|
msg1224 |
Author: [hidden] (richard) |
Date: 2004-06-13 01:45 |
|
Logged In: YES
user_id=6405
Yes, I can reproduce the error. Bugger, I thought I'd nailed it.
Looking into it.
|
msg1225 |
Author: [hidden] (richard) |
Date: 2004-06-21 05:41 |
|
Logged In: YES
user_id=6405
I've fixed the bug that prevented your tracker from migrating.
|
msg1226 |
Author: [hidden] (alexg2000) |
Date: 2004-07-27 00:41 |
|
Logged In: YES
user_id=1059613
Opps, it seems the same error is in 7.6. :-(
|
|
Date |
User |
Action |
Args |
2004-05-08 13:07:39 | gregsf | create | |
|