Adding target leads to Python exception

[W. Martin Borgert]

Hi,

I just installed my first bitten instance with trac 0.11.1. I can add
a configuration in the admin interface, but when I try to add a
platform (button "Add platform", Target platform: "Java", button "Add",
no rules/properties so far), I get an exception:

Traceback (most recent call last):
File "/usr/lib/python2.5/site-packages/trac/web/api.py", line 339,
in send_error
'text/html')
File "/usr/lib/python2.5/site-packages/trac/web/chrome.py", line
702, in render_template
if not req.session or not int(req.session.get('accesskeys', 0)):
File "/usr/lib/python2.5/site-packages/trac/web/api.py", line 169,
in __getattr__
value = self.callbacks[name](self)
File "/usr/lib/python2.5/site-packages/trac/web/main.py", line 257,
in _get_session
return Session(self.env, req)
File "/usr/lib/python2.5/site-packages/trac/web/session.py", line
150, in __init__
self.get_session(req.authname, authenticated=True)
File "/usr/lib/python2.5/site-packages/trac/web/session.py", line
164, in get_session
super(Session, self).get_session(sid, authenticated)
File "/usr/lib/python2.5/site-packages/trac/web/session.py", line
56, in get_session
(sid, int(authenticated)))
File "/usr/lib/python2.5/site-packages/trac/db/util.py", line 50, in execute
return self.cursor.execute(sql_escape_percent(sql), args)
File "/usr/lib/python2.5/site-packages/trac/db/util.py", line 50, in execute
return self.cursor.execute(sql_escape_percent(sql), args)
InternalError: current transaction is aborted, commands ignored until
end of transaction block

Questions:

1. Do I have to define a platform, if I have only one anyway?

2. What's wrong and how can I repair it?

Thanks in advance!

PS: bitten is trunk revision 635, OS is Debian 5.0.

[W. Martin Borgert]

Quoting "W. Martin Borgert" <deb...@debian.org>:
> Questions:
...

3. Any reason why the 'id' in 'bitten_rule' is of type 'text',
not 'serial' nor 'integer'? Changing the type to serial
solved the problem for me.

Cheers!

[Walter W. Bell]

We ran into that problem here when we did our recent upgrade. To keep it simple, we just casted ids in the relevant queries to an int-- I think the right fix is to migrate that column to an int. I'd certainly be in favor of that fix with the corresponding schema upgrade.
-w

[W. Martin Borgert]

Quoting "Walter W. Bell" <wwb...@gmail.com>:
> We ran into that problem here when we did our recent upgrade. To keep it
> simple, we just casted ids in the relevant queries to an int-- I think
> the right fix is to migrate that column to an int. I'd certainly be in
> favor of that fix with the corresponding schema upgrade.

Yes, certainly. Do you remember any other casts/type changes
you needed? E.g. shouldn't 'rev' in 'bitten_build' be integer?

[Simon Cross]

On Tue, May 12, 2009 at 1:41 PM, W. Martin Borgert <deb...@debian.org> wrote:
> Yes, certainly. Do you remember any other casts/type changes
> you needed? E.g. shouldn't 'rev' in 'bitten_build' be integer?

Probably not. Many of the distributed version control systems have
hash strings as revision ids.

[W. Martin Borgert]

Ah, sure, UUIDs and such. In this case, the code has to be changed at
other places, because PostgreSQL is not happy with the current state.

[David Fraser]

There's a ticket which seems to be encompassing the general problem of non-integer columns etc:
http://bitten.edgewall.org/ticket/390
wbell, are you interested in sorting this out?
It would help to have an upgrade script which sorts out the schema mess.

I'm more and more inclined to think that we should have a mass-schema-fixing session so that we can solve all current obvious schema problems in one go rather than in dribs and drabs

David

[Walter W. Bell]

I can take a look at it. It shouldn't be a difficult fix to update the schema for real. I almost feel like fixing the schema piecemeal is the way to go-- it adds a little more time to upgrades, but makes it so that we don't need too much coordination.

One 'major' schema change I have coming down the pipe is the addition of a slave table to keep track of when slaves were around-- during builds, we've added keepalives to the slaves so that builds only expire when there hasn't been a keepalive in a specified amount of time. We've added a 'active slaves' page which keeps track of which slaves we've heard from recently and if they're idle or not. With our 15 slaves, it's a big improvement to know what they're all doing.
-w

[Walter W. Bell]

I've just committed [639], which fixes the only issue we've seen with newer versions of postgres and type massaging. This updates the type of bitten_rule.id to int instead of text and does the proper database upgrade. This should fix #390. Any feedback would be appreciated; as always with a database upgrade, please backup first.

-w

On Tue, 2009-05-12 at 07:39 -0500, David Fraser wrote:

[David Fraser]

Yay, thanks Walter - I marked the ticket as fixed since there aren't svn hook scripts running on commit...

--
David Fraser
St James Software

[David Fraser]

Hi Walter

That's great - although it's a major change to add a new table it's one that's not likely to cause anyone problems, so this should be fine; it's the changes to existing schemas that do that.

Cheers
David

----- "Walter W. Bell" <wwb...@gmail.com> wrote: