[Roundup-devel] [ roundup-Bugs-950410 ] roundup 0.7 failures with mysql backend

[SourceForge.net <no...@so...>]

Bugs item #950410, was opened at 2004-05-08 15:07
Message generated for change (Comment added) made by gregsf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=402788&aid=950410&group_id=31577

Category: Database
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Gregor Schmid (gregsf)
Assigned to: Richard Jones (richard)
Summary: roundup 0.7 failures with mysql backend

Initial Comment:
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

----------------------------------------------------------------------

>Comment By: Gregor Schmid (gregsf)
Date: 2004-06-02 20:52

Message:
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



----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2004-05-25 02:38

Message:
Logged In: YES 
user_id=6405

I'll close this issue in a week if there's no feedback.

----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2004-05-16 00:07

Message:
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 

----------------------------------------------------------------------

Comment By: Gregor Schmid (gregsf)
Date: 2004-05-14 13:03

Message:
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)


----------------------------------------------------------------------

Comment By: Gregor Schmid (gregsf)
Date: 2004-05-14 12:47

Message:
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.

----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2004-05-12 11:30

Message:
Logged In: YES 
user_id=6405

Could you give 0.7.1 a try please? I believe it fixes your 
problem. 

----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2004-05-10 03:27

Message:
Logged In: YES 
user_id=6405

I believe I've fixed this in CVS. 

----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2004-05-10 02:20

Message:
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. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=402788&aid=950410&group_id=31577