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

Bug #340935 reported by James Westby on 2009-03-11
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
wadllib
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

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
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).

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.

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

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

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

Celso Providelo (cprov) wrote :

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

Changed in launchpadlib:
importance: Undecided → High

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) on 2009-03-13
Changed in launchpadlib:
assignee: nobody → thekorn
status: Triaged → In Progress
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

Markus Korn (thekorn) wrote :

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

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) on 2009-07-03
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  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers