[PATCH 1/2] post_translation is called twice on query

[Don Zickus]

I have been fighting with python bugzilla 0.7.0 and 0.8.0 environments for
awhile.  Recently I noticed the rhbz_back_compat flag that would help unify
them until everything is straightened out upstream.

However, setting rhbz_back_compat to True caused my scripts which use 'flags'
to fail.  The reason is the bugzilla.query command.

After querying for a list of bugs, they get post_translated and then returned
to the query command.  The query command the re-initializes the the bugs with a
_Bug object which causes the post_translated bugs to be re-post_translated
again.  This causes a fault with the 'flags' attribute as it goes from a list to
a
string. :-(

The flow is:

bugzilla/base.py::query()
  self._query
    bugzilla/rhbugzilla.py::_query()
      self.post_translation()
  return [_Bug(...]
    bugzilla/bug.py::__init__
      self._update_dict()
          self.bugzilla.post_translation()
           ^^^^OOPS

I don't know the reason the post_translation moved to begin with, but I am just
moving it back to where it was for now.  This fixes my 'flags' issue.

Signed-off-by: Don Zickus <dzickus(a)redhat.com&gt;
---
 bugzilla/bug.py |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/bugzilla/bug.py b/bugzilla/bug.py
index 654d9a9..24bbc59 100644
--- a/bugzilla/bug.py
+++ b/bugzilla/bug.py
@@ -123,6 +123,7 @@ class _Bug(object):
         # Use post_translation to convert getbug results to back compat values
         q = {}
         q["id"] = str(self.bug_id)
+        self.bugzilla.post_translation(q, r)
 
         self._update_dict(r)
 
@@ -131,7 +132,6 @@ class _Bug(object):
         Update internal dictionary, in a way that ensures no duplicate
         entries are stored WRT field aliases
         '''
-        self.bugzilla.post_translation({}, newdict)
 
         for newname, oldname in self.bugzilla.field_aliases:
             if not oldname in newdict:
-- 
1.7.1

[PATCH 2/2] Set rhbz_back_compat default to True

[Don Zickus]

The problem is I have two python bugzilla environments: 0.7.0 and 0.8.0.  Some
windows have the PYTHONPATH set up and get 0.8.0 other do not and get 0.7.0.
The flags attribute is accessed differently in different versions.  Very
annoying.

Now the rhbz_back_compat can fix that.  However, I can't use that variable on
0.7.0 as it doesn't exist.  Boooo!

So to help ease transition to the new reality, set rhbz_back_compat to True for
now.  Then once 0.8.0 is out, folks can slowly set 'rhbz_back_compat' to False
as their scripts are updated.

Then with 0.9.0 comes along, the default can be set to False.

I don't disagree with the change for rhbz_back_compat, I just need (and others
too) a slightly smoother migration path.

Signed-off-by: Don Zickus <dzickus(a)redhat.com&gt;
---
 bugzilla/rhbugzilla.py |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/bugzilla/rhbugzilla.py b/bugzilla/rhbugzilla.py
index becb72e..39ced7d 100644
--- a/bugzilla/rhbugzilla.py
+++ b/bugzilla/rhbugzilla.py
@@ -42,7 +42,7 @@ class RHBugzilla(Bugzilla42):
         """
         # 'multicall' is no longer used, keep it here for back compat
         self.multicall = True
-        self.rhbz_back_compat = False
+        self.rhbz_back_compat = True
 
         if "multicall" in kwargs:
             self.multicall = kwargs.pop("multicall")
-- 
1.7.1

[PATCH 2/2] Set rhbz_back_compat default to True

[Cole Robinson]

On 03/21/2013 02:25 PM, Don Zickus wrote:
>  The problem is I have two python bugzilla environments: 0.7.0 and
> 0.8.0.  Some
>  windows have the PYTHONPATH set up and get 0.8.0 other do not and get 0.7.0.
>  The flags attribute is accessed differently in different versions.  Very
>  annoying.
>  
>  Now the rhbz_back_compat can fix that.  However, I can't use that variable on
>  0.7.0 as it doesn't exist.  Boooo!
>  
>  So to help ease transition to the new reality, set rhbz_back_compat to True for
>  now.  Then once 0.8.0 is out, folks can slowly set 'rhbz_back_compat' to False
>  as their scripts are updated.
>  
>  Then with 0.9.0 comes along, the default can be set to False.
>  
>  I don't disagree with the change for rhbz_back_compat, I just need (and others
>  too) a slightly smoother migration path.
>   
Thanks for the patch Don, however I'd like to avoid this if possible.

python-bugzilla-0.8.0 has been available in updates-testing for F17+ and
epel5/6 for a month now. I realize updates-testing isn't the most obvious
thing to some users, but that should be all the upgrade path we need. Is that
sufficient or am I missing something?

0.8.0 changed a lot of things, so it's probably going to break things for some
people. Turning this option on by default is going to postpone some of the
complaints until a future date. But what I really want is to get all the
complaints/breakage/bugreports condensed into the narrowest time window
possible to ease the maintenance burden. So turning this option back on is an
absolute last resort in my mind.

Also, you can always do

rhbz = RHBugzilla(url=...,...)
rhbz.rhbz_back_compat = True

on both 0.7.0 and 0.8.0 so at least code will be compatible, although of
course that option will do nothing on 0.7.0.

Thanks,
Cole

[PATCH 2/2] Set rhbz_back_compat default to True

[Don Zickus]

On Mon, Mar 25, 2013 at 04:24:01PM -0400, Cole Robinson wrote:
>  On 03/21/2013 02:25 PM, Don Zickus wrote:
>  > The problem is I have two python bugzilla environments: 0.7.0 and 0.8.0.  Some
>  > windows have the PYTHONPATH set up and get 0.8.0 other do not and get 0.7.0.
>  > The flags attribute is accessed differently in different versions.  Very
>  > annoying.
>  > 
>  > Now the rhbz_back_compat can fix that.  However, I can't use that variable on
>  > 0.7.0 as it doesn't exist.  Boooo!
>  > 
>  > So to help ease transition to the new reality, set rhbz_back_compat to True for
>  > now.  Then once 0.8.0 is out, folks can slowly set 'rhbz_back_compat' to
> False
>  > as their scripts are updated.
>  > 
>  > Then with 0.9.0 comes along, the default can be set to False.
>  > 
>  > I don't disagree with the change for rhbz_back_compat, I just need (and others
>  > too) a slightly smoother migration path.
>  > 
>  
>  Thanks for the patch Don, however I'd like to avoid this if possible.
>  
>  python-bugzilla-0.8.0 has been available in updates-testing for F17+ and
>  epel5/6 for a month now. I realize updates-testing isn't the most obvious
>  thing to some users, but that should be all the upgrade path we need. Is that
>  sufficient or am I missing something?
>  
>  0.8.0 changed a lot of things, so it's probably going to break things for some
>  people. Turning this option on by default is going to postpone some of the
>  complaints until a future date. But what I really want is to get all the
>  complaints/breakage/bugreports condensed into the narrowest time window
>  possible to ease the maintenance burden. So turning this option back on is an
>  absolute last resort in my mind.
>  
>  Also, you can always do
>  
>  rhbz = RHBugzilla(url=...,...)
>  rhbz.rhbz_back_compat = True
>  
>  on both 0.7.0 and 0.8.0 so at least code will be compatible, although of
>  course that option will do nothing on 0.7.0. 
Ok.  My main concern was getting something that works for 0.7.0 and 0.8.0.
The above trick might work.  Let me play with it.

Thanks,
Don

[Cole Robinson]

On 03/21/2013 02:25 PM, Don Zickus wrote:
>  I have been fighting with python bugzilla 0.7.0 and 0.8.0
> environments for
>  awhile.  Recently I noticed the rhbz_back_compat flag that would help unify
>  them until everything is straightened out upstream.
>  
>  However, setting rhbz_back_compat to True caused my scripts which use 'flags'
>  to fail.  The reason is the bugzilla.query command.
>  
>  After querying for a list of bugs, they get post_translated and then returned
>  to the query command.  The query command the re-initializes the the bugs with a
>  _Bug object which causes the post_translated bugs to be re-post_translated
>  again.  This causes a fault with the 'flags' attribute as it goes from a list to
> a
>  string. :-(
>  
>  The flow is:
>  
>  bugzilla/base.py::query()
>    self._query
>      bugzilla/rhbugzilla.py::_query()
>        self.post_translation()
>    return [_Bug(...]
>      bugzilla/bug.py::__init__
>        self._update_dict()
>            self.bugzilla.post_translation()
>             ^^^^OOPS
>   
Thanks for pointing this out. Indeed something is wrong here.

>  I don't know the reason the post_translation moved to begin with,
> but I am just
>  moving it back to where it was for now.  This fixes my 'flags' issue.
>   
The reason it was moved is that there are several other places where we
initialize a _Bug() but were never calling post_translation: getbug* and
createbug. I tried to stick it in a central place (_update_dict) so we would
get it for free everywhere. This should also be fixed by dropping the
post_translation call in rhbugzilla.py, done now:

http://git.fedorahosted.org/cgit/python-bugzilla.git/commit/?id=5217a0c91...

However post_translation also should be safe to run multiple times, at least
to prevent this type of issue in the future. I fixed that up and added some
unittests to make sure it all works:

http://git.fedorahosted.org/cgit/python-bugzilla.git/commit/?id=5217a0c91...

Please confirm that latest git fixes the original issue.

Thanks,
Cole

[Don Zickus]

On Mon, Mar 25, 2013 at 04:14:51PM -0400, Cole Robinson wrote:
>  On 03/21/2013 02:25 PM, Don Zickus wrote:
>  > I have been fighting with python bugzilla 0.7.0 and 0.8.0 environments for
>  > awhile.  Recently I noticed the rhbz_back_compat flag that would help unify
>  > them until everything is straightened out upstream.
>  > 
>  > However, setting rhbz_back_compat to True caused my scripts which use
> 'flags'
>  > to fail.  The reason is the bugzilla.query command.
>  > 
>  > After querying for a list of bugs, they get post_translated and then returned
>  > to the query command.  The query command the re-initializes the the bugs with a
>  > _Bug object which causes the post_translated bugs to be re-post_translated
>  > again.  This causes a fault with the 'flags' attribute as it goes from a
> list to a
>  > string. :-(
>  > 
>  > The flow is:
>  > 
>  > bugzilla/base.py::query()
>  >   self._query
>  >     bugzilla/rhbugzilla.py::_query()
>  >       self.post_translation()
>  >   return [_Bug(...]
>  >     bugzilla/bug.py::__init__
>  >       self._update_dict()
>  >           self.bugzilla.post_translation()
>  >            ^^^^OOPS
>  > 
>  
>  Thanks for pointing this out. Indeed something is wrong here.
>  
>  > I don't know the reason the post_translation moved to begin with, but I am just
>  > moving it back to where it was for now.  This fixes my 'flags' issue.
>  > 
>  
>  The reason it was moved is that there are several other places where we
>  initialize a _Bug() but were never calling post_translation: getbug* and
>  createbug. I tried to stick it in a central place (_update_dict) so we would
>  get it for free everywhere. This should also be fixed by dropping the
>  post_translation call in rhbugzilla.py, done now:
>  
>
> http://git.fedorahosted.org/cgit/python-bugzilla.git/commit/?id=5217a0c91...
>  
>  However post_translation also should be safe to run multiple times, at least
>  to prevent this type of issue in the future. I fixed that up and added some
>  unittests to make sure it all works:
>  
>
> http://git.fedorahosted.org/cgit/python-bugzilla.git/commit/?id=5217a0c91...
>  
>  Please confirm that latest git fixes the original issue. 
Yes, flipping back and forth using old and new 'flag' styles with your
rhbz.rhbz_back_compat trick in the other email, shows everything working
as I expect it (meaning it failed properly and succeeded too).

Thanks!

Cheers,
Don