Launchpad itself

Cannot access bug_watch in a bugtask

Bug #322135 reported by Bryce Harrington
2
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
High
Gavin Panella
Launchpad itself 2.2.2

Bug Description

Possibly I'm just confused. What I'm trying to do is detect if a given bug has been reported upstream. I'm not sure if there's a simple way of doing this, but so far I'm trying to do it this way:

    # Count upstream watch
    for peertask in bugtask.related_tasks:
        if peertask.bug_target_display_name.endswith("(Ubuntu)"):
            continue
        dump_launchpad_object(peertask)

        if peertask.bug_watch:
            print "Has a bug watch"

The dump indicates it has a bug_watch attr, but then complains that bug_watch doesn't exist...

<bug_task at https://api.edge.launchpad.net/beta/xorg-server/+bug/237993>
 attr: ['bug_target_display_name', 'bug_target_name', 'bug_watch', 'date_assigned', 'date_closed', 'date_confirmed', 'date_created', 'date_fix_committed', 'date_fix_released', 'date_in_progress', 'date_left_closed', 'date_left_new', 'date_triaged', 'http_etag', 'importance', 'is_complete', 'resource_type_link', 'self_link', 'status', 'title']
 ops: ['transitionToAssignee', 'transitionToImportance', 'transitionToStatus']
 coll: ['related_tasks']
 entr: ['assignee', 'bug', 'owner']

Traceback (most recent call last):
  File "./stats-bugs.py", line 40, in <module>
    if peertask.bug_watch.remote_bug:
  File "build/bdist.linux-x86_64/egg/launchpadlib/resource.py", line 454, in __getattr__
  File "build/bdist.linux-x86_64/egg/launchpadlib/resource.py", line 301, in __getattr__
AttributeError: 'Entry' object has no attribute 'bug_watch'

Tags: api lp-bugs
Revision history for this message
Gavin Panella (allenap) wrote :

bug_watch is exported as a Choice instead of a ReferenceChoice. There was a similar (unreleased) bug to this yesterday! We must find a way to prevent these types of bug.

Changed in launchpadlib:
importance: Undecided → High
Changed in malone:
milestone: none → 2.2.2
status: New → Triaged
Revision history for this message
Gavin Panella (allenap) wrote :

As a work around you could do:

    >>> for peertask in bugtask.related_tasks:
    ... if peertask.bug_target_display_name.endswith("(Ubuntu)"):
    ... continue
    ... dump_launchpad_object(peertask)
    ... if len(peertask.bug.bug_watches) > 0:
    ... print "Has a bug watch"

That only tells you if the bug has a watch; it may not be associated
with this particular bug task. If you need to know that, try:

    >>> for peertask in bugtask.related_tasks:
    ... if peertask.bug_target_display_name.endswith("(Ubuntu)"):
    ... continue
    ... dump_launchpad_object(peertask)
    ... # Don't do this!
    ... watch_link = task._wadl_resource.representation['bug_watch_link']
    ... if watch_link is not None:
    ... print "Has a bug watch"

That's ugly and nasty, but it should work for now. I don't know of any
plans to change the internals of launchpadlib, but it /could/ change
at any moment, so don't forget to revert any hack when the fix is
released.

Revision history for this message
Christian Reis (kiko) wrote : Re: [Bug 322135] Re: Cannot access bug_watch in a bugtask

On Wed, Jan 28, 2009 at 09:28:23AM -0000, Gavin Panella wrote:
> bug_watch is exported as a Choice instead of a ReferenceChoice. There
> was a similar (unreleased) bug to this yesterday! We must find a way to
> prevent these types of bug.

Hmmm. Wouldn't a simple test of the API ensure that we were exporting
the right thing?

Revision history for this message
Gavin Panella (allenap) wrote :

[Launchpad has screwed up the whitespace, so I'll try again.]

As a work around you could do:

    for peertask in bugtask.related_tasks:
        if peertask.bug_target_display_name.endswith("(Ubuntu)"):
            continue
        dump_launchpad_object(peertask)
        if len(peertask.bug.bug_watches) > 0:
            print "Has a bug watch"

That only tells you if the bug has a watch; it may not be associated
with this particular bug task. If you need to know that, try:

    for peertask in bugtask.related_tasks:
        if peertask.bug_target_display_name.endswith("(Ubuntu)"):
            continue
        dump_launchpad_object(peertask)
        # Don't do this!
        watch_link = task._wadl_resource.representation['bug_watch_link']
        if watch_link is not None:
            print "Has a bug watch"

That's ugly and nasty, but it should work for now. I don't know of any
plans to change the internals of launchpadlib, but it /could/ change
at any moment, so don't forget to revert any hack when the fix is
released.

Revision history for this message
Gavin Panella (allenap) wrote :

@kiko: There are tests, and the JSON returned from the API calls is correct, but they work below launchpadlib. The issue here is, if I understand correctly, is when launchpadlib uses the Launchpad API WADL to generate classes. Exporting bug_watch as a Choice instead of a ReferenceChoice causes the WADL to be slightly different, so the generated classes are subtly wrong.

Revision history for this message
Christian Reis (kiko) wrote :

On Wed, Jan 28, 2009 at 10:02:59AM -0000, Gavin Panella wrote:
> @kiko: There are tests, and the JSON returned from the API calls is
> correct, but they work below launchpadlib.

Ah, and only an integration test would be able to catch whether or not
the class is generated correctly.

Revision history for this message
Gavin Panella (allenap) wrote :

Yes, that's a much more concise way of saying it :)

If you're interested, this diff <http://paste.ubuntu.com/110772/> shows the effect on the generated WADL that changing from Choice to ReferenceChoice has.

Gavin Panella (allenap)
Changed in malone:
assignee: nobody → allenap
status: Triaged → In Progress
Revision history for this message
Gavin Panella (allenap) wrote :

In trunk r7693.

Changed in malone:
status: In Progress → Fix Committed
Gavin Panella (allenap)
Changed in malone:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.