Resources are only instantiated using the WADL predicted type, not the actual found type

Bug #340935 reported by James Westby
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
wadllib
Triaged
Low
Unassigned

Bug Description

Hi,

I was glad to see target exposed on bug_task, as I thought it would
lead to a time where I didn't have to use

   task.bug_target_name.endswith("(Ubuntu)")

to detect if a task was an Ubuntu task.

However, target is a DistributionSourcePackage, but it only exposes
searchTasks. It should at least expose distribution and source package
name in my opinion.

Thanks,

James

Revision history for this message
Julian Edwards (julian-edwards) wrote :

James, as far as I can see, it does expose those attributes:
https://edge.launchpad.net/+apidoc/#distribution_source_package

Is that enough?

Changed in soyuz:
status: New → Incomplete
Revision history for this message
Celso Providelo (cprov) wrote :

I think James means first https://edge.launchpad.net/+apidoc/#bug_task API, it has 'bug_target_name' and 'target'.

The latter points to a https://edge.launchpad.net/+apidoc/#bug_target which is pretty much a end-of-line object atm, since you can only call 'searchTasks' (which, at most, can send you to the point you were at the beginning).

Let me know if I'm mistaken, but it doesn't seem to be a problem in Soyuz/DistributionSourcePackage, but instead in Malone/BugTarget, which lacks a link to the actual 'target' (Distribution, DistroSeries, DistributionSourcePackage, Product, etc).

Revision history for this message
Julian Edwards (julian-edwards) wrote :

Right, I had the same thoughts when I read the description but then the bug title is pretty unequivocal.

If James does mean the bug objects, then this should be re-targeted on Malone.

Revision history for this message
James Westby (james-w) wrote :

Hi,

Apologies if I misfiled this. Allow me to be more precise in what I am seeing:

In [5]: bug = lp.load("https://api.edge.launchpad.net/beta/bugs/bugtrackers/debbugs/505113")

In [6]: task = bug.bug_tasks[0]

In [7]: task.bug_target_name
Out[7]: u'rescue (Ubuntu)'

In [8]: task.target
Out[8]: <distribution_source_package at https://api.edge.launchpad.net/beta/ubuntu/+source/rescue>

In [9]: type(task.target)
Out[9]: <class 'launchpadlib.resource.Entry'>

In [10]: task.target.self_link
Out[10]: u'https://api.edge.launchpad.net/beta/ubuntu/+source/rescue'

In [11]: task.target.resource_type_link
Out[11]: u'https://api.edge.launchpad.net/beta/#distribution_source_package'

In [12]: task.target.distribution

so it claims to be "distribution_source_package", but doesn't have the interesting
properties of that object, though I just noticed it does have "bug_reporting_guidelines".

It's not clear to me which part of launchpad is at fault, so please re-assign as
you see fit.

Thanks,

James

Revision history for this message
Celso Providelo (cprov) wrote :

Right, that's a bug_target pretending to be a distribution_source_package. Try this workaround:

{{{
>>> dsp = lp.load(task.target.self_link)
>>> dsp.distribution
<distribution at https://api.edge.launchpad.net/beta/ubuntu>
>>> dsp.name
u'rescue'
>>> dsp.display_name
u'rescue in ubuntu'
}}}

That's a bug in the way bug_target are created/exposed, IMO. Let's check what the malone guys have to say.

Changed in soyuz:
status: Incomplete → Triaged
Revision history for this message
James Westby (james-w) wrote : Re: [Bug 340935] Re: DistributionSourcePackage doesn't expose enough of its attributes

On Thu, 2009-03-12 at 00:31 +0000, Celso Providelo wrote:
> Right, that's a bug_target pretending to be a
> distribution_source_package. Try this workaround:
>
> {{{
> >>> dsp = lp.load(task.target.self_link)

Thanks Celso, nice trick.

James

Revision history for this message
Eleanor Berger (intellectronica) wrote : Re: DistributionSourcePackage doesn't expose enough of its attributes

Is this not actually a launchpadlib bug?

Revision history for this message
Celso Providelo (cprov) wrote :

Right, I've not thought about this obvious possibility ;)

Changed in launchpadlib:
importance: Undecided → High
Revision history for this message
Leonard Richardson (leonardr) wrote : Re: Resources should be instantiated using their actual type, not the WADL specified one

I think we can consider this a launchpadlib bug. The WADL file describes the document type at the other end of task_target. It's accurate, but in this case there's a more detailed description of that document available. The link to this other, more detailed description is in the document's resource_type_link.

So launchpadlib should use a document's actual resource_type_link in preference to any resource_type it obtained earlier from another source. The document's resource_type_link, if present, will never be less accurate than the other source.

Markus Korn (thekorn)
Changed in launchpadlib:
assignee: nobody → thekorn
status: Triaged → In Progress
Revision history for this message
Markus Korn (thekorn) wrote :

I think I fixed this in the attached branch, and filed a merge proposal at https://code.edge.launchpad.net/~thekorn/launchpadlib/fix-340935-bug_target/+merge/4452

Revision history for this message
Markus Korn (thekorn) wrote :

After talking to Leonard I reconsidered my fix. I now think this bug should be fixed in wadllib

Revision history for this message
Markus Korn (thekorn) wrote :

Fixed in the attached branch of wadllib and filed a merge request at https://code.edge.launchpad.net/~thekorn/wadllib/fix-340935-use-actual-type/+merge/4484

Markus Korn (thekorn)
Changed in wadllib:
assignee: Markus Korn (thekorn) → nobody
status: In Progress → Confirmed
Changed in wadllib:
status: Confirmed → Triaged
Changed in wadllib:
importance: High → Low
summary: - Resources should be instantiated using their actual type, not the WADL
- specified one
+ Resources are only instantiated using the WADL predicted type, not the
+ actual found type
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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