I've just done a migration from sqlite to mysql. The only problem I had was when I exported the database from sqlite Date properties in one of my issue classes journal files were getting exported in the form <Date 2007-10-12....> i.e. the python class representation rather than a tuple. This was for actions of type "create".

When I tried to import that csv the eval fails on that. 

I fixed my immediate issue by modifying rdbms_common.py:export_journal.py and import_journal.py to output an eval'able value using the code already there for action type set.

Here's a patch:

--- rdbms_common.py     Wed Aug  1 10:28:17 2007
+++ /app/roundup/src/roundup-1.3.3/roundup/backends/rdbms_common.py     Tue Dec 19 03:00:29 2006
@@ -2509,7 +2509,7 @@
         for nodeid in self.getnodeids():
             for nodeid, date, user, action, params in self.history(nodeid):
                 date = date.get_tuple()
-                if action in ('create', 'set'):
+                if action == 'set':
                     export_data = {}
                     for propname, value in params.items():
                         if not properties.has_key(propname):
@@ -2542,7 +2542,7 @@
             l = map(eval, l)
             nodeid, jdate, user, action, params = l
             r = d.setdefault(nodeid, [])
-            if action in ('set', 'create'):
+            if action == 'set':
                 for propname, value in params.items():
                     prop = properties[propname]
                     if value is None:

Do you know how I could reproduce this? Your patch looks okay to me but I don't know the import/export very well yet so I'd like to it failing live to try to understand this one. Thanks.

The easiest way is probably to setup a sqlite db with at least one issue class which has a date. Add a few issues and add a bunch of responses to the issue(s) to cause some records to be written into the journal and then export it.

Then try to reimport it (not sure if the db type matters). That's when it occurred for me (well during a migration from sqlite to mysql). The dates written into the exported datafile will look like python class instances <Date
2007-10-12....> which can't be imported.

I tried creating a sqlite db and adding a new Date field to the issue class then creating an issue, setting some fields, and exporting the result. I was unable to reproduce the problem you're describing.

The problem you saw was on 'create' actions not dealing with parameters properly. From what I can tell, though, create events don't have parameters in the journal. If you look at the end of create_inner for the backends you'll see something like:

if self.do_journal:
  self.db.addjournal(self.classname, newid, 'create', {})

There shouldn't be any Date objects (or anything else) in create events to confuse the exporter. So I'm not certain how you're seeing what you are.

However, I did discover that it hasn't always been this way. A long time ago (the change was Nov 6, 2002 for the 0.5.3 release I think) 'create' events *did* store parameters in the journal. Is there any chance your database is that old?

I guess I'm at a loss how to reproduce your problem. From what I can tell, it shouldn't be happening with the current roundup unless you have some data from before 2003 :-/ I'm loath to commit a fix when I don't understand what is going on.....

This problem was caused by old (old) trackers actually storing data in the create entry of the item journal.

Trackers don't do this any more.

I've put in code to specially handle export and import where create events have data, and clear that data.