V0.6 not working on Trac1.0

[peter]

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")

[Steffen Hoffmann]

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.

[Steffen Hoffmann]

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.

[Ryan J Ollos]

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.

[Steffen Hoffmann]

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.