Opened 18 years ago
Closed 18 years ago
#4467 closed defect (duplicate)
bugzilla2trac fails during insert into TICKET_CHANGE - integrity error
Reported by: | Andy Hardy | Owned by: | Jonas Borgström |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | general | Version: | 0.10.1 |
Severity: | normal | Keywords: | bugzilla2trac.py |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
Bugzilla2trac (r3544), Bugzilla version 2.20 is running under MySQL 4.1.13 on a SuSE box, Trac 0.10.1 with sqlite is running on a Windows 2003 server.
I'm new to Trac and have never looked at Python, but hope that the enclosed details make sense to someone who understands!
The import failed with an integrity error referring to the TICKET_CHANGE table. I put some 'print' statements around the addTicketChange function to see if there was an obvious problem. It appears that the "time" returned from Bugzilla is visible (prints in the form of "YYYY-MM-DD HH24:MI:SS") , but the use of strftime('%s') against it results in a null - which eventually causes the integrity error to appear.
It seems to me that the sqlite ticket_change table is using an integer to store dates? So I guessed that it might actually be expecting something equivalent to a mktime result?
My workaround was to add a: time_mktime = mktime(strptime(time.strftime("%Y-%m-%d %H:%M:%S"), "%Y-%m-%d %H:%M:%S"))
to each function that deals with storing dates and then used the time_mktime value directly in the insert It seems to work for me.
Not sure why the original doesn't work on my setup or whether this is a proper fix, but happy to pass on to someone who knows how this is all intended to work!
Attachments (2)
Change History (5)
by , 18 years ago
Attachment: | bugzilla2trac.patch added |
---|
comment:1 by , 18 years ago
I had the same problem with Bugzilla 2.20 and r3544 of bugzilla2trac.py. I don't know Python at all, so excuse the lousy code, but I did what Andy Hardy suggested and, but it still didn't always work. So I also wrapped it with exception handling so it continues to the next bug instead of stop the entire process (we have a large Bugzilla database and it wasn't fun to have to keep debugging and re-running it for the bugs it fails to import). I've attached a patch so that others can get it working. It outputs the bug number it failed on so you can check the bugs by hand after the import (it does seem to drop the change events).
It only failed for me when inserting into ticket_change, for what it's worth. I don't know why it occasionally can't parse the date formats from Bugzilla, though, the dates look fine when looking directly at the Bugzilla database.
comment:2 by , 18 years ago
I did a little more investigation and, in my case, the date was being parsed correctly, there really was duplicate ticket_change records being added. This is because in Bugzilla you can add an attachment and post a comment at the same time so there's 2 changes at the same time. Trac doesn't support this so you lose the text the person entered when attaching a file.
I fixed it with a much simpler patch, just add "OR IGNORE" (or "OR REPLACE" depending on your preference) in the SQL. This lets it run, but again, you lose the text the person entered. Fortunately, most of the bugs that we had this problem with were closed bugs so we don't care. We just copied the lost comment manually in those that needed it.
Still, the bug should be fixed, IMO.
comment:3 by , 18 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
#4724 comes with an updated script which probably takes care of this issue as well.
Patch for at least one problem