New install impossible on Trac 1.0beta1

[Benjamin Lau]

I was trying to evaluate test manager for trac on a fresh install of 1.0beta1 and ran into the following error:

19:53:36 Trac[env] ERROR: Exception caught while checking for upgrade: 
Traceback (most recent call last):
  File "build/bdist.macosx-10.7-intel/egg/trac/env.py", line 832, in open_environment
    needs_upgrade = env.needs_upgrade()
  File "build/bdist.macosx-10.7-intel/egg/trac/env.py", line 665, in needs_upgrade
    if participant.environment_needs_upgrade(db):
  File "build/bdist.macosx-10.7-intel/egg/tracgenericclass/model.py", line 1276, in environment_needs_upgrade
    return (self._need_initialization(db) or self._need_upgrade(db))
  File "build/bdist.macosx-10.7-intel/egg/tracgenericclass/model.py", line 1311, in _need_initialization
    return self._need_upgrade(db)
  File "build/bdist.macosx-10.7-intel/egg/tracgenericclass/model.py", line 1322, in _need_upgrade
    db.rollback()
  File "build/bdist.macosx-10.7-intel/egg/trac/db/util.py", line 107, in __getattr__
    raise AttributeError
AttributeError:

Looking into this it looks like a common problem that many plug-ins have been having during the 1.0 release cycle. #10230 #9742 Looking at the solution used in #10230 I've produced a patch for test manager that at least allows it to install. I'm not sure if this is the right way to deal with this since it looks like #9742 uses a slightly more complex approach.

[Roberto Longobardi]

Hi jetjunki, thanks a lot for trying this out and for providing a patch.

I've taken a look at this and the other issues during the w/e, followed the posts on the trac-users mailing list and reviewed the ​Trac DB API.

It looks like the approach to db transaction management has been changed quite a bit, and I'm still figuring out how to support Trac 0.11, 0.12 and 1.0 (and Python 2.5, 2.6 and 2.7) with the same code base.

I don't want to fork the code to support the distinct environments, so I'll try to figure out some way of supporting them altogether, like I did for I18N and L10N.

If you wish to help out with this, aven since my free cycles these days are very limited, please let me know and we can get together to devise something.

Ciao, Roberto

[Benjamin Lau]

TagsPlugin seems to deal with this like so. I've CC'd hasienda since I figure he might have some insight into this issue and the "right" approach to dealing with it.

I'd be more than happy to prepare a patch for you.

@hasienda from the comment on changeset 11041:

The logical next step is switching to the recommended procedure of storing explicite db schema versions inside the Trac db like other plugins already do.

What did you mean by this? Can you point me to a plug-in that is using this technique?

[Steffen Hoffmann]

Replying to netjunki:

TagsPlugin seems to deal with this like so. I've CC'd hasienda since I figure he might have some insight into this issue and the "right" approach to dealing with it.

Thanks for asking. The best way to go is indeed not obvious at first glance at this issue.

@hasienda from the comment on changeset 11041:

The logical next step is switching to the recommended procedure of storing explicite db schema versions inside the Trac db like other plugins already do.

What did you mean by this? Can you point me to a plug-in that is using this technique?

Sure, i.e. there is ScreenshotsPlugin (see: source:screenshotsplugin/0.12/tracscreenshots/init.py​), or an own alteration of mine in TracFormsPlugin (see source:tracformsplugin/tags/tracforms-0.4.1/0.11/tracforms/tracdb.py​)

And I really want to make TracTags use the Trac db table system as well before next release of that plugin. Anything else should be for corner-cases, one-time, like upgrading to a system-aware version.

[Roberto Longobardi]

Hi all, sorry I'm only finding today some time to work on this.

The plugin already works with database versions. You can look at the files under ​testman4trac/testmanager/trunk/upgrades

Anyway, it is a proprietary model that does not use the basic Trac utilities for this.

It would be a good idea to switch to the Trac-provided API for this, I only have to find some time to make it happen.

I also already do something to have a db access code that works on both 0.11 and 012. You can take a look at ​the TracGenericClass util module, where I check for Trac compatibility with several APIs like timestamps and db access.

Hasienda approach to db API compatibility is similar to what I do with I18N, in ​TestManager's api module from line 54.

I think yours is the right approach and we should use it for test manager too, but the change seems not so simple or limited...

@netjunki, do you have some free cycles to work on this change?

Otherwise, I'll try to find some one of these w/e's.

Let me know.

Ciao, Roberto

[Benjamin Lau]

I have some cycles this weekend probably. I was planning to work on a new hack (some sort of Google Drive integration) but I think I need this first... so that can wait. I'll try and take a look over the weekend. I'd recently been asked by management to eval a proprietary tool for test tracking... but I think I'd rather have something integrated with trac which I could then improve on based on feedback from my company's QA team.

[Roberto Longobardi]

OK, that sounds great!

Also, if you want to discuss your company's QA team requirements, I'm always happy to enhance the plugin functionalities.

Let's keep in touch this w/e.

Ciao, Roberto

[Roberto Longobardi]

Fixed the compatibility with Trac 1.0 in release 1.5.1!!! :D

Thanks netjunky for your initial patch.

I had to do a lot of work on the database API.

In addition to that, I also integrated the DB version check and upgrade mechanism with the standard Trac one (i.e. storing DB version info inside the system table, instead of my own table as before).

Check it out here: ​https://sourceforge.net/projects/testman4trac/files/