Upgrading from 0.5.6 to 0.6.2 and adding new fields to
the issue class:
While upgrading we also added some new fields to our
tracker. A reproduceable behaviour was that we lost
*all* standard class information that is present in any
class: creation, creator, activity. The fields were
simply empty. We are using the sqlite backend, so
migrating this information from the old backup database
was not a problem since we had a backup. Maybe there is
a problem in the sqlite backend code for changing
roundup database schema?

Logged In: YES 
user_id=6405

This is quite disturbing, since it means that the journal is being dropped 
(or cleared) somehow. That doesn't make sense *at all* since I've had a 
look at the code and the only time the journal is dropped is when classes 
are removed *outright* from the schema. If that was the case, then all 
of the *items* for the class would also have disappeared. 
 
Please, if you have a chance look at the 
roundup/backends/rdbms_common.py code and see if you come to a 
different conclusion. I see only one place that has the journal table being 
dropped, and that's in drop_class - which is called when classes are 
removed from the schema. 
 
You mentioned changing the item ids to a number type - is there a 
chance that the journal lookup is failing because the numeric id isn't 
matching the old string id in the journal? 
 

Logged In: YES 
user_id=6405

Will close this issue if I don't get a response. 

Logged In: YES 
user_id=34818

Richard, please don't close yet, I will look into this when
time permits, hopefully within the next two weeks. I suspect
the following behaviour:
- We changed the database schema from within sqlite also in
our own tracker installation from which we were upgrading.
In particular the "ID" field was of type "integer". 
- With some of our detectors we experienced that we got the
id as a numeric value in python, not as a string
- Maybe when changing the schema some of the field contents
was not moved because the lookup (looking up with a string
ID for a value that is an integer or vice versa) might have
cause the problem. 
So this is probably caused by us hacking the SQL schema but
a fix might nevertheless prove beneficial if you intend to
change the type of some of roundup's types to 'integer' in
an SQL database. So I'll investigate this and try to find
out where the things get lost.
Ralf

Logged In: YES 
user_id=6405

I *am* interested in migrating over to numeric ids - it'll solve another 
issue that James Kew has noticed with ordering. So if you could keep 
track of the problems you've run into, that would be *excellent*! 
 

Logged In: YES 
user_id=6405

I have been unable to reproduce the behaviour stated here, so 
I'm closing the issue.