Opened 19 years ago
Closed 17 years ago
#2808 closed defect (wontfix)
sourceforge2trac importer does not work (with postgres)
Reported by: | Owned by: | Jonas Borgström | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | general | Version: | 0.9.4 |
Severity: | normal | Keywords: | sourceforge2trac unicode |
Cc: | Branch: | ||
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
The sourceforge2trac contrib script fails due to not using the DB-API correctly and assuming sqlite internals. It also seems to cause segmentation faults whenever it tries to add a ticket with non-ASCII characters.
Attachments (1)
Change History (6)
by , 19 years ago
Attachment: | sf2trac.ptc added |
---|
comment:1 by , 19 years ago
comment:2 by , 19 years ago
Well, I guess a simple .encode('utf-8') will work with UNICODE/UTF8 databases, right?
This will probably become a non-issue if/when the unicode branch is merged.
comment:3 by , 17 years ago
Milestone: | 1.0 |
---|
Unicode branch merged quite some time ago (0.10), but would be nice to get verification that this ticket can be closed. #3521 with patch proves recent success with import, so hopefully someone can confirm this issue also for non-ascii characters.
comment:4 by , 17 years ago
I'm afraid I don't have either the data or resources to verify this; I ran into this for a one time migration and have not used or touched any sf trackers since.
comment:5 by , 17 years ago
Keywords: | sourceforge2trac unicode added |
---|---|
Resolution: | → wontfix |
Status: | new → closed |
So, to be reopened if needed.
This patch tries to fix this. The solution is not optimal: it just does a nasty encode("ascii","replace) on all data to strip non-ASCII character. Unless a unicode-aware postgres connection is used this might be the only way to get this working unfortunately.