Modify

Opened 8 years ago

Closed 6 years ago

Last modified 5 years ago

#1217 closed defect (fixed)

database upgrade fails after installing latest scrumburndownplugin

Reported by: tompr@… Owned by: daan
Priority: high Component: ScrumBurndownPlugin
Severity: blocker Keywords:
Cc: Trac Release: 0.10

Description

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

Attachments (2)

mysql.patch (3.1 KB) - added by anonymous 7 years ago.
Patch to make burndown to work with mysql 5
1217.diff (970 bytes) - added by mark@… 7 years ago.
Can't insert NULL into burndown.id--it's a non-null primary key.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 7 years ago by sambloomquist

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;"""
        ]

comment:2 Changed 7 years ago by 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.

comment:3 Changed 7 years ago by 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!

comment:4 follow-up: Changed 7 years ago by 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!

comment:5 in reply to: ↑ 4 ; follow-up: Changed 7 years ago by 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.

comment:6 in reply to: ↑ 5 Changed 7 years ago by 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.

Changed 7 years ago by anonymous

Patch to make burndown to work with mysql 5

comment:7 Changed 7 years ago by 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

comment:8 Changed 7 years ago by 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.

Changed 7 years ago by mark@…

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

comment:9 Changed 6 years ago by reverend

thanks for the mysql.patch

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

comment:10 Changed 6 years ago by daan

  • Owner changed from sambloomquist to daan

comment:11 Changed 6 years ago by daan

  • Resolution set to fixed
  • Status changed from new to closed

(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

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.