Modify

Opened 23 months ago

Closed 23 months ago

Last modified 23 months ago

#10368 closed defect (duplicate)

V0.6 not working on Trac1.0

Reported by: peter Owned by: hasienda
Priority: normal Component: TagsPlugin
Severity: major Keywords: ProgrammingError upgrade db
Cc: Trac Release: 1.0

Description

Problem with V0.6 on Trac1.0

While doing a GET operation on /tags, Trac issued an internal error.

I've checked the FAQ and help for this plugin, can't be sure whether I can use on Trac1.0. Please let me know. ProgrammingError: (1146, "Table 'alchipwiki.tags' doesn't exist")

Request parameters:

{}

User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.89 Safari/537.1

System Information

Trac 1.0
Babel 0.9.5
Genshi 0.6 (without speedups)
mod_wsgi 3.2 (WSGIProcessGroup WSGIApplicationGroup %{GLOBAL})
MySQL server: "5.1.52", client: "5.1.52", thread-safe: 0
MySQLdb 1.2.3c1
Pygments 1.1.1
Python 2.6.6 (r266:84292, Dec 7 2011, 20:48:22)
[GCC 4.4.6 20110731 (Red Hat 4.4.6-3)]
pytz 2010h
setuptools 0.6
Subversion 1.6.11 (r934486)
jQuery 1.7.2

Enabled Plugins

TracAccountManager 0.3.2
TracTags 0.6

Python Traceback

Traceback (most recent call last):
  File "/usr/lib/python2.6/site-packages/Trac-1.0-py2.6.egg/trac/web/main.py", line 497, in _dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.6/site-packages/Trac-1.0-py2.6.egg/trac/web/main.py", line 214, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/lib/python2.6/site-packages/TracTags-0.6-py2.6.egg/tractags/web_ui.py", line 99, in process_request
    data['tag_body'] =  macro.expand_macro(formatter, None, query)
  File "/usr/lib/python2.6/site-packages/TracTags-0.6-py2.6.egg/tractags/macros.py", line 59, in expand_macro
    for resource, tags in query_result:
  File "/usr/lib/python2.6/site-packages/TracTags-0.6-py2.6.egg/tractags/api.py", line 196, in query
    for resource, tags in provider.get_tagged_resources(req, query_tags):
  File "/usr/lib/python2.6/site-packages/TracTags-0.6-py2.6.egg/tractags/api.py", line 92, in get_tagged_resources
    cursor.execute(sql, args)
  File "/usr/lib/python2.6/site-packages/Trac-1.0-py2.6.egg/trac/db/util.py", line 65, in execute
    return self.cursor.execute(sql_escape_percent(sql), args)
  File "/usr/lib64/python2.6/site-packages/MySQLdb/cursors.py", line 173, in execute
    self.errorhandler(self, exc, value)
  File "/usr/lib64/python2.6/site-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
    raise errorclass, errorvalue
ProgrammingError: (1146, "Table 'alchipwiki.tags' doesn't exist")

Attachments (0)

Change History (4)

comment:1 Changed 23 months ago by hasienda

  • Keywords ProgrammingError upgrade db added
  • Resolution set to duplicate
  • Status changed from new to closed

This is due to changes in the Trac db layer as well as a flawed way of this plugin to handle db schema upgrades. It will be fixed in tags-0.7, so the development code in trunk is meant to go into the right direction.

In any case, please follow-up on #9521 instead of opening yet another ticket on this issue.

comment:2 Changed 23 months ago by hasienda

To clarify: tags-0.6 might never work with Trac >= 1.0, until someone really make a stance, why a back-port of the upcoming solution is strictly required.

However, I recommend to upgrade the plugin instead of wasting my and your time trying to convince me to waste even more time.

This isn't meant offensive at all. Because there is not much third-party support for TagsPlugin other than my own efforts, 0.6 is almost dead. There's not much more about it. Thanks for taking care, and hopefully for understanding the situation.

comment:3 Changed 23 months ago by rjollos

We could even consider adding a Trac version check, as described in comment:4:ticket:9800. I've started implementing that for a number of plugins I maintain (e.g. [12040]). Usually, I'm implementing a min version check though.

Of course, that we require creating a new tag, 0.6.1, and pushing users away from 0.6 and towards 0.6.1, which might create as much confusion as it has the potential to avoid.

comment:4 Changed 23 months ago by hasienda

tags-0.7 is on the way.

I've created all the code to finally get a sane, full-fledged db schema handling using best-practice code, mostly borrowed from Trac core and my WiP CryptoPlugin sources. Only I have to test and decide, if/how to go on with pending performance tweaks.

I've been the first to point at the issue with Trac 0.13dev, long before Trac 1.0 was even mentioned. However I've seen few care-taking, if any, until now. A few more days don't justify hacking around this problem.

With tags-0.7 we'll be back in deep water very soon. Know the Debian slogan: It's finished when it's finished.? This time I stick to it too.

Add Comment

Modify Ticket

Action
as closed .
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from hasienda. Next status will be '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.