[patch] bugzilla2trac.py for postgresql

[munro@…]

Hi

To import bugs from Bugzilla into a PostgreSQL database, I needed to make a couple of very minor alterations to the bugzilla2trac.py script (see attached patch which applies to the trunk).

Thomas Munro

[munro@…]

Note that after importing into a new postgres database with bugzilla2trac.py, you also need to update the sequences:

trac⇒ SELECT SETVAL('ticket_id_seq', MAX(id)) FROM ticket; trac⇒ SELECT SETVAL('report_id_seq', MAX(id)) FROM report;

I suppose this could be incorporated into the bugzilla2trac.py script, but it would have to detect that it was talking to postgres as a special case.

[asmodai@…]

Aside from one small encode (#2229) all changes from this are in the current version, save the id change.

[asmodai@…]

When #2229 gets committed this one can be closed as well.

The current version of the script uses the more portable get_last_id() call, which nowadays (0.9b1+) also supports PostgreSQL.

[Christopher Lenz]

Fixed in [2356].

[klaus@…]

The trunk version did not work for me. I had an undefined Error for 'report_id_seq' when calling get_last_id in line 351.

I had to execute """SELECT SETVAL('ticket_id_seq', MAX(id)) FROM ticket; SELECT SETVAL('report_id_seq', MAX(id)) FROM report""" right before calling get_last_id to make the script working.

I can attach the patch file if needed, but the change is rather trivial. I don't know if executing the selects is dirty or not.

Btw my trac version is 0.9.3 but I tried the trunc version of bugzilla2trac.py too.

[sid]

path attached, needs to be reviewed

[sid]

Removing review keyword. I see that the attached patch has already been incorporated into trunk in [2356]. The only thing remaining is if the change in comment:6 should be incorporated into trunk.

[Christian Boos]

Eventually someone should take care of the maintenance of the bugzilla2trac.py contrib script.

[osimons]

Time has passed on this ticket. Some things have already been incorporated as mentioned, but there has also been some 20+ more recent tickets with input and fixes for this script. No good reason to keep this ticket open any longer with a patch from 2005.

Closing as 'seemstoworkforothers'.

[shanec@…]

Replying to osimons:

Time has passed on this ticket. Some things have already been incorporated as mentioned, but there has also been some 20+ more recent tickets with input and fixes for this script. No good reason to keep this ticket open any longer with a patch from 2005.

Closing as 'seemstoworkforothers'.

I can verify this is still an issue with .11 and the current script. Comment # 6 does provide the solution.

In TracDatabase:init I added:

from trac.db.api import DatabaseManager self.using_postgres = DatabaseManager(self.env).connection_uri.startswith("postgres:")

then just before the call to get_last_id I added:

if self.using_postgres:

c.execute("""SELECT SETVAL('ticket_id_seq', MAX(id)) FROM ticket;

SELECT SETVAL('report_id_seq', MAX(id)) FROM report""")

[anonymous]

Replying to shanec@…:

I can verify this is still an issue with .11 and the current script. Comment # 6 does provide the solution.

In TracDatabase:init I added:

from trac.db.api import DatabaseManager self.using_postgres = DatabaseManager(self.env).connection_uri.startswith("postgres:")

then just before the call to get_last_id I added:

if self.using_postgres:

c.execute("""SELECT SETVAL('ticket_id_seq', MAX(id)) FROM ticket;

SELECT SETVAL('report_id_seq', MAX(id)) FROM report""")

Thankyou thankyou thankyou for this… It is indeed still a problem and your SELECT SETVAL code finally sorted the problem for me. I also identified some other issues with importing more than one product at a time (see #8566)

[Christian Boos]

Replying to shanec@…:

Replying to osimons: …

Closing as 'seemstoworkforothers'.

I can verify this is still an issue with .11 and the current script. comment:6 does provide the solution.

In TracDatabase:init I added: …

Care to provide a patch?

[admiralnemo@…]

I don't know if anyone else has any use for it, but I had to patch bugzilla2trac.py to support my Bugzilla, which uses PostgreSQL as its database backend. It uses psycopg2 since it complies with PEP 249 like MySQLdb, so it is essentially a drop-in replacement. I also incorporated the workaround in comment:6, since my Trac environment also uses PostgreSQL.

I also had to make a small change regarding Bugzilla's initialowner and username resolution. I don't know if something changed between Bugzilla releases or not, but I added a new clause to the conditional that checks for Bugzilla versions greater than 3.0. If someone knows more about this, feel free improve.

Finally, I don't *think* this breaks existing MySQL functionality, but I don't have a MySQL database/Bugzilla to test against, so let me know if I overlooked something.

Comments welcome.

[admiralnemo@…]

Add support for PostgreSQL-backed Bugzilla as well

[Christian Boos]

Replying to admiralnemo@…:

… Comments welcome.

Looks good, but I think the patch doesn't apply anymore cleanly. Can you please refresh it against current source:trunk/contrib/bugzilla2trac.py?

[Ryan J Ollos]

bugzilla2trac.py is no longer maintainer by Trac developers and is being deleted from the trunk. If you need the plugin, please consider copying it from 1.4-stable​ and creating a plugin on ​trac-hacks.org.