I have been using roundup for a few weeks now and it is 
very good. But one particular issue (number 37) in the 
db has suddenly got a bit confused. A new message 
was added to this issue using web interface. The next 
time we did a "show all" we got a template error 
complaining that this issue 37 did not exist. I checked 
using roundup-admin and found that this issue has 
appeared to have lost its creator and creation date (but 
has everything else).

roundup> list issue creator
Traceback (most recent call last):
  File "C:\ODT02L~1\PROG\PYTHON22\lib\site-
packages\roundup\admin.py", line 1131
, in run_command
    ret = function(args[1:])
  File "C:\ODT02L~1\PROG\PYTHON22\lib\site-
packages\roundup\admin.py", line 727,
 in do_list
    value = cl.get(nodeid, propname)
  File "C:\ODT02L~1\PROG\PYTHON22\lib\site-
packages\roundup\backends\back_anydbm
.py", line 1026, in get
    journal = self.db.getjournal(self.classname, nodeid)
  File "C:\ODT02L~1\PROG\PYTHON22\lib\site-
packages\roundup\backends\back_anydbm
.py", line 514, in getjournal
    raise IndexError, 'no such %s %s'%(classname, 
nodeid)
IndexError: no such issue 37

roundup> spec issue
status: <roundup.hyperdb.Link to "status">
category: <roundup.hyperdb.Link to "category">
topic: <roundup.hyperdb.Multilink to "keyword">
assignedto: <roundup.hyperdb.Link to "user">
messages: <roundup.hyperdb.Multilink to "msg">
title: <roundup.hyperdb.String>
nosy: <roundup.hyperdb.Multilink to "user">
superseder: <roundup.hyperdb.Multilink to "issue">
files: <roundup.hyperdb.Multilink to "file">
priority: <roundup.hyperdb.Link to "priority">

roundup> display issue37
status: 6
category: 6
topic: ['4']
assignedto: None
messages: ['37', '197']
title: Restore quick setting for priorities: metro/rural
nosy: []
superseder: []
files: []
priority: 4

To fix this for now I have retired issue 37. 

Any ideas as to what caused this? Any way this be 
repaired rather than retired?

Thanks.

Logged In: YES 
user_id=6405

Which backend are you using? 

Logged In: NO 

I just selected anydbm (how do I find out exactly which 
backend is being used?).
Is there a recommended back-end? 
What about sqlite?
If I need to change back-end is it possible to migrate current 
data across (using import/export I guess)?

Thanks for your help.

Logged In: YES 
user_id=6405

anydbm means the journals are stored in a separate dbm file (and the journal 
holds the creator information). If the journal entry for issue 37 got deleted, 
then accesses to the journal entry would fail as you've demonstrated 
above. Stuffed if I know why the journal entry would be deleted - there's no 
code in Roundup to do that. I can only suspect that a write to the journal 
failed mid-way through an update. This is the first occurance of such a 
thing happening that I can recall. Definitely bad though. Are the 
permissions of the files in your tracker's db directory all the same? 
 
To migrate to a new backend, you would do the export and import (I've 
done it a few times myself ;) 
 

Logged In: NO 

All permissions in db dir are the same. 
I have had no problems since issue 37 failed, and we have 
been using it quite a lot in a prod environment.
(In general, roundup has been working very well - I am very 
impressed by its simplicity and flexibility).
I am thinking about testing sqlite as alternative backend - just 
in case this happens again.

Thanks,
Paul

Logged In: YES 
user_id=6405

This might be related to the anydbm double-close bug that I've fixed in the  
CVS. It's the only thing I can think of...  
  
I'll close this issue since I can't reproduce it.