AttributeError: 'Environment' object has no attribute 'get_db_cnx'

[elambrid@…]

Not sure how to get around this error. I have the following enabled in components in trac.ini: [components] tracfullblog.* = enabled

Thanks in advance for any help!

How to Reproduce

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

(please provide additional details here)

User agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0

System Information

Trac	1.1.2beta1
Babel	1.3 (translations unavailable)
FullBlog	0.1.1-r13462
Genshi	0.7 (with speedups)
pysqlite	2.6.0
Python	2.7.2 (default, Oct 2 2014, 14:57:02) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)]
pytz	2014.7
setuptools	6.0.2
SQLite	3.6.20
jQuery	1.8.3
jQuery UI	1.9.2
jQuery Timepicker	1.1.1

Enabled Plugins

TracFullBlogPlugin

0.1.1-r13462

Python Traceback

Traceback (most recent call last):
  File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 550, in _dispatch_request
    dispatcher.dispatch(req)
  File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 224, in dispatch
    resp = chosen_handler.process_request(req)
  File "/home1/astrobet/python272/lib/python2.7/site-packages/TracFullBlogPlugin-0.1.1_r13462-py2.7.egg/tracfullblog/web_ui.py", line 119, in process_request
    data['blog_about'] = BlogPost(self.env, 'about')
  File "/home1/astrobet/python272/lib/python2.7/site-packages/TracFullBlogPlugin-0.1.1_r13462-py2.7.egg/tracfullblog/model.py", line 372, in __init__
    self._load_post(version)
  File "/home1/astrobet/python272/lib/python2.7/site-packages/TracFullBlogPlugin-0.1.1_r13462-py2.7.egg/tracfullblog/model.py", line 511, in _load_post
    fields = self._fetch_fields(version)
  File "/home1/astrobet/python272/lib/python2.7/site-packages/TracFullBlogPlugin-0.1.1_r13462-py2.7.egg/tracfullblog/model.py", line 480, in _fetch_fields
    self.versions = self.get_versions()
  File "/home1/astrobet/python272/lib/python2.7/site-packages/TracFullBlogPlugin-0.1.1_r13462-py2.7.egg/tracfullblog/model.py", line 457, in get_versions
    cnx = self.env.get_db_cnx()
AttributeError: 'Environment' object has no attribute 'get_db_cnx'

[Ryan J Ollos]

Replying to elambrid@…:

Not sure how to get around this error. I have the following enabled in components in trac.ini: [components] tracfullblog.* = enabled

The plugin is not yet compatible with Trac 1.1.2. Unless you can provide a patch you'll need to wait for the plugin to be adapted to the Trac 1.0 API.

[Ryan J Ollos]

Would you accept a patch for Trac 1.0 compatibility that assumes a new branch will be made, or do you intend to retain backwards compatibility to 0.11 on a single codeline? FullBlogPlugin will be much more challenging to keep on a single codeline vs XmlRpcPlugin simply due to the number of database queries. There are a number of other changes that could/need to be made as well:

• macros.html is deprecated and removed by Trac 1.2.
• attach_file_form.html is deprecated and removed by Trac 1.2.
• Entry in System Information is redundant with plugin versions table (since 0.12?)
• SQL debugging statements can be removed since Trac has a debug_sql option (since 0.12?)

[osimons]

Most database access is already abstracted into sql and args for execution (and debugging), so calling some compat handler should not be a big deal. As for macros.html and friends, I don't quite remember what (if anything) I actually use. It seems the inclusion is just done in all templates by default. Couldn't compat handling in templates just be solved by using xi:fallback if unavailable?

So yes, I would really like to avoid branching for internal changes only.

[sdegrande]

I attached a quick patch for 1.2 compatibility, for those needed it without waiting the actual upgrade of the plugin.

Thx four your work.

[osimons]

Thanks for the patch! Looks like a great starting point for integration.

For template compat code, dropping macros.html for templates not using any functions is obviously no problem. But for the last template, something like this should work:

tracfullblog/templates/fullblog_view.html

@@ -5 +5 @@
       xmlns:py="http://genshi.edgewall.org/"
       xmlns:xi="http://www.w3.org/2001/XInclude">
   <xi:include href="layout.html" />
-  <xi:include href="macros.html" />
+  <xi:include href="macros.html"><xi:fallback /></xi:include>
   <head>
     <title>Blog${defined('blog_post') and ': ' + blog_post.title \
                 or req.args.get('blog_path') and defined('blog_list_title') \
@@ -45 +45 @@
                   <input type="submit" value="${_('Edit post')}" accesskey="e" />
                 </div>
               </form>
-              ${attach_file_form(blog_attachments)}
+              <py:choose test="defined('attach_file_form')">
+                <py:when test="True">
+                  ${attach_file_form(blog_attachments)}
+                </py:when>
+                <py:when test="False">
+                  <xi:include href="attach_file_form.html"
+                              py:with="alist = blog_attachments"/>
+                </py:when>
+              </py:choose>
               <form method="get" action="${href.blog('delete', blog_post.name)}"
                     py:if="'BLOG_DELETE' in perm(blog_post.resource)">
                 <div>
@@ -57 +65 @@
           </py:if>
         
           <!--! List attachments -->
-          ${list_of_attachments(blog_attachments, compact=True)}
+          <py:choose test="defined('list_of_attachments')">
+            <py:when test="True">
+              ${list_of_attachments(blog_attachments, compact=True)}
+            </py:when>
+            <py:when test="False">
+              <xi:include href="list_of_attachments.html"
+                          py:with="alist = blog_attachments; compact = True"/>
+            </py:when>
+          </py:choose>
 
           <!--! View comments -->
           <div id="comments" py:with="blog_comments = blog_post.get_comments()">

[sdegrande]

I do not have any right to give any advice about your desire to keep backward compatibility, but just a small question, if I may: if all those installs with an old Trac do not upgrade to a more recent version, do they however update plugins ? If not, it is really worth trying to keep compatibility of the plugins, instead of just branching ? Just my very small piece of coin...

[osimons]

I just dislike branching for internal changes. I may also want to branch for plugin needs (like breaking changes in plugin api), and both as a developer and a user I want to avoid having to use tables like ​trac:wiki:TracMercurial#Releases

One version to rule them all ;-)

[osimons]

Trac 1.2 compat changes for db and templates.

[osimons]

I've now full reviewed the patch by sdegrande and integrated all changes in a compatible way. May not be the prettiest but as far as I can tell the plugin now also works with latest Trac trunk.

Please test attachment:t12018-trac_1_compat.diff​​ and I'll get it committed.

[osimons]

In 14886:

FullBlogPlugin: Trac 1.2 compat handling for database and templates. Closes #12018.

[osimons]

Thanks for the patch, sdegrande! I just went ahead and committed the integrated effort. Should be fine.

Please reopen ticket if further compat issues are found.