Opened 6 years ago

Closed 6 years ago

# New install impossible on Trac 1.0beta1

Reported by: Owned by: Benjamin Lau Benjamin Lau normal TestManagerForTracPlugin normal AttributeError upgrade db Steffen Hoffmann 1.0

### Description

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
File "build/bdist.macosx-10.7-intel/egg/trac/env.py", line 665, in needs_upgrade
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
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.

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

### comment:2 follow-up:  3 Changed 6 years ago by Benjamin Lau

Cc: Steffen Hoffmann added; anonymous removed changed from Roberto Longobardi to Benjamin Lau new → assigned

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?

### comment:3 in reply to:  2 Changed 6 years ago by Steffen Hoffmann

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.

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

### comment:5 Changed 6 years ago by Benjamin Lau

Status: assigned → new

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.

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

### comment:7 Changed 6 years ago by Roberto Longobardi

Resolution: → fixed new → closed

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/

### Modify Ticket

Change Properties