I was making some changes in the database using the python interface.
At some point I removed a message:

  db.msg.destroy("230")

Afterwards I iterate over all issues:

  for id in db.issue.list():
      print "Checking", id
      priority = db.issue.get(id, "priority")
      ....
      
this failed with the error:

  ..
  Checking 97
  Checking 98
  Checking 99
  
  Traceback (most recent call last):
    File "./check-tracker.py", line 118, in ?
      priority = db.issue.get(id, "priority")
    File "/home/nikratio/stow//lib/python2.4/site-packages/roundup/backends/rdbms_common.py", line 1467, in get
      d = self.db.getnode(self.classname, nodeid)
    File "/home/nikratio/stow//lib/python2.4/site-packages/roundup/backends/rdbms_common.py", line 987, in getnode
      del self.cache[self.cache_lru.pop()]
  KeyError: ('msg', '280')


I couldn't quite understand why retrieving the priority of issue 99
would result in a key error mentioning message 280. msg280 is bound to
issue17 and issue99 only has one message msg159. Nevertheless I tried
to add db.commit() after deleting the message, but the error
persisted.

However, if I only deleted the message, committed and then restarted
the script to only iterate through the issues, everything worked fine.
I therefore suspect that there is some problem with the internal
caching. 


Note: It seems that I can also reproduce this most of the time with other issues as well.

I have investigated this a bit more and I am now able to reproduce it every time that I delete in issue. Unless I reopen the database (using instance.open("path_to_db")), a loop over all issues will fail with the above KeyError.

I realize it has been a while, but what backend were you using
and do you have a simple test case that I can run?

Also you are a bit of an edge case. You shouldn't be deleting items.
Retiring them is the preferred method to keep referential integrity.

Why did you want to delete the message entry? Also note that message
content/text isn't kept in the db, it's in a disk file under the
tracker's db/file directory IIRC. So if you had a password or something
submitted deleting the message doesn't delete the message content.

-- rouilj

Closing as abandoned. Not surprising after all this time.