database upgrade fails after installing latest scrumburndownplugin

[tompr@…]

Hello;

I'm attempting to install TracBurndown-01.05.10-py2.3.egg on a Centos 4.3 system with Trac 0.10.3. I'm using PostGres on the backend (versions included below). I'm able to install 'timingandestimationplugin' without error, and see hours in tickets when I run reports. However, after installing the TracBurndown-01.05.10-py2.3.egg, I execute the trac-admin command and get the following error message:

[root@nile scrumplugin]# trac-admin /opt/tracpg upgrade --no-backup Command failed: ERROR: adding columns with defaults is not implemented HINT: Add the column, then use ALTER TABLE SET DEFAULT.

I'm not sure how to fix this, but I'm suspecting that the issue lies with the version of Postgres I'm using vs. the version of SQL DB this was developed on.

Any help would be appreciated.

Thanks

Tom

(postgres versions)

postgresql-libs-7.4.16-1.RHEL4.1 postgresql-odbc-7.3-8.RHEL4.1 postgresql-contrib-7.4.16-1.RHEL4.1 postgresql-server-7.4.16-1.RHEL4.1 postgresql-docs-7.4.16-1.RHEL4.1 postgresql-python-7.4.8-1.RHEL4.1 postgresql-devel-7.4.16-1.RHEL4.1 postgresql-pl-7.4.16-1.RHEL4.1 postgresql-tcl-7.4.8-1.RHEL4.1 postgresql-test-7.4.16-1.RHEL4.1 postfix-2.1.5-4.2.RHEL4 postgresql-jdbc-7.4.8-1.RHEL4.1 postgresql-7.4.16-1.RHEL4.1

[Sam Bloomquist]

My best guess is that the problem is in the SQL that updates the milestone table to add a 'started' column. This error sounds like maybe postgres doesn't like the default value of 0 that is passed in to the 'INSERT INTO milestone' statement. I really don't have much familiarity with postrgres, so if anyone else out there does, I'd appreciate a little help on this one.

sqlMilestone = [
        #-- Add the 'started' column to the milestone table
        """CREATE TEMP TABLE milestone_old AS SELECT * FROM milestone;""",
        """DROP TABLE milestone;""",
        """CREATE TABLE milestone (
                 name            text PRIMARY KEY,
                 due             integer, -- Due date/time
                 completed       integer, -- Completed date/time
                 started        integer, -- Started date/time
                 description     text
        );""",
        """INSERT INTO milestone(name,due,completed,started,description)
        SELECT name,due,completed,0,description FROM milestone_old;"""
        ]

[anonymous]

Hi, I am using PostgreSQL 8.1 on Fedora with Python 2.4. Since the SQL statements in burndown.py didn't work, I just created the tables myself using the pgAdmin gui Query tool.

To create the burndown table:

CREATE TABLE burndown
(
  id int4 NOT NULL,
  component_name text NOT NULL,
  milestone_name text NOT NULL,
  date text,
  week text,
  "year" text,
  hours_remaining int4 NOT NULL,
  CONSTRAINT burndown_pkey PRIMARY KEY (id)
) 

To backup the existing milestone table as milestone_old before I alter it:

CREATE TABLE milestone_old AS SELECT * FROM milestone;

To alter the existing milestone table:

ALTER TABLE milestone ADD COLUMN started int4;
ALTER TABLE milestone ALTER COLUMN started SET STORAGE PLAIN;
ALTER TABLE milestone ALTER COLUMN started SET DEFAULT 0;

Once this is complete, running trac-admin /path/to/project upgrade --no-backup shows Database is up to date, no upgrade necessary.

And everything should just work. Good luck to my fellow Postgres users.

[anonymous]

Me again -- when I tried to run burndown_job.py, it failed. I fixed it by dropping and recreating the burndown table and editing the burndown_job.py script.

There were two basic problems with my burndown table SQL above:

• burndown.id was int4 NOT NULL but burndown_job.py tries to insert NULL
• burndown.hours_remaining was int4 which will not accept a decimal like 6.5000

So first, drop your existing burndown table - which shouldn't be too much of a loss because burndown_job.py wouldn't run, so it is empty.

Then create burndown like this:

CREATE TABLE burndown
(
  id serial NOT NULL,
  component_name text NOT NULL,
  milestone_name text NOT NULL,
  date text,
  week text,
  "year" text,
  hours_remaining float4 NOT NULL,
  CONSTRAINT burndown_pkey PRIMARY KEY (id)
)
WITHOUT OIDS;
ALTER TABLE burndown OWNER TO <your trac db owner>; 

Choosing to make id serial instead of int4 should create sequence burndown_id_seq:

CREATE SEQUENCE burndown_id_seq
  INCREMENT 1
  MINVALUE 1
  MAXVALUE 9223372036854775807
  START 1
  CACHE 1;
ALTER TABLE burndown_id_seq OWNER TO <your trac db owner>;

Now edit burndown_job.py changing lines 75-76 from:

cursor.execute("INSERT INTO burndown(id,component_name, milestone_name, date, hours_remaining) "\
                    "    VALUES(NULL,'%s','%s','%s',%f)" % (comp[0], mile[0], today, hours))
}}

to

{{{
cursor.execute("INSERT INTO burndown(component_name, milestone_name, date, hours_remaining) "\
"    VALUES('%s','%s','%s',%f)" % (comp[0], mile[0], today, hours))
}}}

And test running the burndown_job.py pointed at your Trac environment directory.  Everything should work fine.  Thanks to sambloomquist for this cool plugin!

[anonymous]

Oops! That last bit should have been:

Now edit burndown_job.py changing lines 75-76 from:

cursor.execute("INSERT INTO burndown(id,component_name, milestone_name, date, hours_remaining) "\
                    "    VALUES(NULL,'%s','%s','%s',%f)" % (comp[0], mile[0], today, hours))

to

cursor.execute("INSERT INTO burndown(component_name, milestone_name, date, hours_remaining) "\
"    VALUES('%s','%s','%s',%f)" % (comp[0], mile[0], today, hours))

And test running the burndown_job.py pointed at your Trac environment directory. Everything should work fine. Thanks to sambloomquist for this cool plugin!

[anonymous]

Replying to anonymous:

Oops! That last bit should have been:

Now edit burndown_job.py changing lines 75-76 from:

cursor.execute("INSERT INTO burndown(id,component_name, milestone_name, date, hours_remaining) "\
                    "    VALUES(NULL,'%s','%s','%s',%f)" % (comp[0], mile[0], today, hours))

to

cursor.execute("INSERT INTO burndown(component_name, milestone_name, date, hours_remaining) "\
"    VALUES('%s','%s','%s',%f)" % (comp[0], mile[0], today, hours))

And test running the burndown_job.py pointed at your Trac environment directory. Everything should work fine. Thanks to sambloomquist for this cool plugin!

Hi, I did exactly as you wrote (created the database and modified the burndown_job.py), and than I runned the file bellow, but I got an error message:

python burndown_job.py /opt/trac/aea/

Traceback (most recent call last):

File "burndown_job.py", line 82, in ?

main()

File "burndown_job.py", line 33, in main

cursor.execute("SELECT id FROM burndown WHERE date = '%s'" % today)

File "/usr/lib64/python2.4/site-packages/trac/db/util.py", line 51, in execute

return self.cursor.execute(sql)

File "/usr/lib64/python2.4/site-packages/trac/db/util.py", line 51, in execute

return self.cursor.execute(sql)

psycopg2.ProgrammingError: permission denied for relation burndown

I downloaded the version 01.06.10 Could you help me? Thanks in advance.

[anonymous]

This is the original Postgres poster. Sorry you're having a problem. The version of the plugin I am using is revision 2171, and I don't have time to update unfortunately because I have a big stack of actual work work to do.

However, if you check out version 2171, these instructions should work. Turn on debug logging on your database and Trac - that was very helpful when I was trying to figure out where things weren't working.

Replying to anonymous:

Replying to anonymous:

Oops! That last bit should have been:

Now edit burndown_job.py changing lines 75-76 from:

cursor.execute("INSERT INTO burndown(id,component_name, milestone_name, date, hours_remaining) "\
                    "    VALUES(NULL,'%s','%s','%s',%f)" % (comp[0], mile[0], today, hours))

to

cursor.execute("INSERT INTO burndown(component_name, milestone_name, date, hours_remaining) "\
"    VALUES('%s','%s','%s',%f)" % (comp[0], mile[0], today, hours))

And test running the burndown_job.py pointed at your Trac environment directory. Everything should work fine. Thanks to sambloomquist for this cool plugin!

Hi, I did exactly as you wrote (created the database and modified the burndown_job.py), and than I runned the file bellow, but I got an error message:

python burndown_job.py /opt/trac/aea/

Traceback (most recent call last):

File "burndown_job.py", line 82, in ?

main()

File "burndown_job.py", line 33, in main

cursor.execute("SELECT id FROM burndown WHERE date = '%s'" % today)

File "/usr/lib64/python2.4/site-packages/trac/db/util.py", line 51, in execute

return self.cursor.execute(sql)

File "/usr/lib64/python2.4/site-packages/trac/db/util.py", line 51, in execute

return self.cursor.execute(sql)

psycopg2.ProgrammingError: permission denied for relation burndown

I downloaded the version 01.06.10 Could you help me? Thanks in advance.

[anonymous]

Patch to make burndown to work with mysql 5

[anonymous]

i'm getting the following error trying to upgrade my project. i'm using postgres as well

Attempting to create the burndown table Command failed: current transaction is aborted, commands ignored until end of transaction block

[anonymous]

I just installed 01.08.10 on postgres and the instructions for postgres above do work. If you're having a problem then you need to double check the changes you made. In particular, ensure that you are applying the "ALTER TABLE <table> OWNER TO <user>" sections.

[mark@…]

Can't insert NULL into burndown.id--it's a non-null primary key.

[reverend]

thanks for the mysql.patch

but i actually don't know how to use it. can you plz give a short description?

[daan]

(In [5058]) Release of version 1.9.1 of the Trac Scrum burndown plugin. See ​http://stuq.nl/weblog/2008-12-25/scrum-burndown-plugin-191-released for more information.

A new version of the Scrum Burndown plugin for Trac is released, bringing compatibility for PostgreSQL, MySQL, Trac 0.11.2.1, and many bug fixes. Upgrading is recommended.

New features The Scrum burndown plugin is currently compatible and tested with Trac 0.10.5, Trac 0.11.1, Trac 0.11.2.1 Python 2.4 and Python 2.5. Additional to the previous SQLite compatibility, support for both PostgreSQL 8.3 and MySQL 5 has been added.

The following issues are fixed:

• Fixes #1462 better control of milestone: a way to ‘reset’ a milestone
• Fixes #1217 database upgrade fails after installing latest scrumburndownplugin
• Fixes #2476 Error: ‘line_graph’ is undefined - stop graph from displaying
• Fixes #1730 couldn’t upgrade
• Fixes #2729 Error while running under PostgreSQL
• Fixes #3102 burndown_job.py fails INSERT NULL id
• Fixes #1909 Overshooting estimate reduces remaining effort while ticket is open
• Fixes #1189 TracBurndown-01.05.10-py2.4.egg error
• Fixes #1800 No chart when clicking Burndown chart button.
• Fixes #4047 AttributeError: ‘NoneType’ object has no attribute ‘getValue’
• Fixes #2224 Changing ticket component causes removal from burndown
• Fixes #2562 Creating a new component breaks the burndown graphic for “All Components”
• Fixes #4222 Install fails on mysql
• Fixes #2218 ScrumBurndownPlugin, trac 0.10.4, mysql