Roundup Tracker - Issues

Issue 950410

classification
roundup 0.7 failures with mysql backend
Type: Severity: normal
Components: Database Versions:
process
Status: closed fixed
:
: richard : alexg2000, gregsf, richard
Priority: normal :

Created on 2004-05-08 13:07 by gregsf, last changed 2012-10-10 11:48 by admin.

Files
File name Uploaded Description Edit Remove
qj2.tar.gz gregsf, 2004-06-11 17:13 Complete tracker to reproduce the problem
Messages
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. :-(
History
Date User Action Args
2004-05-08 13:07:39gregsfcreate