#10368 closed defect (duplicate)
V0.6 not working on Trac1.0
Reported by: | peter | Owned by: | Steffen Hoffmann |
---|---|---|---|
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 12 years ago by
Keywords: | ProgrammingError upgrade db added |
---|---|
Resolution: | → duplicate |
Status: | new → closed |
comment:2 Changed 12 years ago by
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 12 years ago by
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 12 years ago by
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.
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.