Modify

Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#12018 closed defect (fixed)

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

Reported by: elambrid@… Owned by: osimons
Priority: normal Component: FullBlogPlugin
Severity: normal Keywords:
Cc: Ryan J Ollos Trac Release: 1.2

Description

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'

Attachments (3)

SystemInformation.png (105.1 KB) - added by Ryan J Ollos 4 years ago.
fix_1.2_compat.diff (26.6 KB) - added by sdegrande 4 years ago.
t12018-trac_1_compat.diff (24.0 KB) - added by osimons 4 years ago.
Trac 1.2 compat changes for db and templates.

Download all attachments as: .zip

Change History (14)

comment:1 in reply to:  description Changed 5 years ago by Ryan J Ollos

Trac Release: 1.2

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.

comment:2 Changed 5 years ago by Ryan J Ollos

Cc: Ryan J Ollos added

Changed 4 years ago by Ryan J Ollos

Attachment: SystemInformation.png added

comment:3 Changed 4 years ago by 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?)

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

Changed 4 years ago by sdegrande

Attachment: fix_1.2_compat.diff added

comment:5 Changed 4 years ago by 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.

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

    a b  
    55      xmlns:py="http://genshi.edgewall.org/"
    66      xmlns:xi="http://www.w3.org/2001/XInclude">
    77  <xi:include href="layout.html" />
    8   <xi:include href="macros.html" />
     8  <xi:include href="macros.html"><xi:fallback /></xi:include>
    99  <head>
    1010    <title>Blog${defined('blog_post') and ': ' + blog_post.title \
    1111                or req.args.get('blog_path') and defined('blog_list_title') \
     
    4545                  <input type="submit" value="${_('Edit post')}" accesskey="e" />
    4646                </div>
    4747              </form>
    48               ${attach_file_form(blog_attachments)}
     48              <py:choose test="defined('attach_file_form')">
     49                <py:when test="True">
     50                  ${attach_file_form(blog_attachments)}
     51                </py:when>
     52                <py:when test="False">
     53                  <xi:include href="attach_file_form.html"
     54                              py:with="alist = blog_attachments"/>
     55                </py:when>
     56              </py:choose>
    4957              <form method="get" action="${href.blog('delete', blog_post.name)}"
    5058                    py:if="'BLOG_DELETE' in perm(blog_post.resource)">
    5159                <div>
     
    5765          </py:if>
    5866       
    5967          <!--! List attachments -->
    60           ${list_of_attachments(blog_attachments, compact=True)}
     68          <py:choose test="defined('list_of_attachments')">
     69            <py:when test="True">
     70              ${list_of_attachments(blog_attachments, compact=True)}
     71            </py:when>
     72            <py:when test="False">
     73              <xi:include href="list_of_attachments.html"
     74                          py:with="alist = blog_attachments; compact = True"/>
     75            </py:when>
     76          </py:choose>
    6177
    6278          <!--! View comments -->
    6379          <div id="comments" py:with="blog_comments = blog_post.get_comments()">

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

comment:8 Changed 4 years ago by 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 ;-)

Changed 4 years ago by osimons

Attachment: t12018-trac_1_compat.diff added

Trac 1.2 compat changes for db and templates.

comment:9 Changed 4 years ago by 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.

comment:10 Changed 4 years ago by osimons

Resolution: fixed
Status: newclosed

In 14886:

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

comment:11 Changed 4 years ago by 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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain osimons.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.