Error caused by binding to anonymous collection resource

Bug #529998 reported by James Westby
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
wadllib
New
Undecided
Unassigned

Bug Description

I think I've found a bug in either wadllib or lazr.restfulclient.

Consider this:

  <wadl:method id="person-getBugs" name="GET">
     <wadl:request>
       <wadl:param style="query" name="ws.op" required="true"
                   fixed="getBugs">
     </wadl:request>
     <wadl:response>
        <wadl:representation href="%(root)s#bugs-page"/>
     </wadl:response>
  </wadl:method>

which defines a getBugs method that returns an anonymous collection of
bugs.

  <wadl:resource_type id="bugs-page-resource">
    <wadl:method name="GET" id="bugs-page-resource-get">
      <wadl:response>
          <wadl:representation href="#bugs-page" />
      </wadl:response>
    </wadl:method>
  </wadl:resource_type>

  <wadl:representation mediaType="application/json" id="bugs-page">
    <wadl:param style="plain" name="resource_type_link"
                path="$['resource_type_link']">
      <wadl:link/>
    </wadl:param>
    <wadl:param style="plain" name="total_size" path="$['total_size']"
                required="true"/>
    <wadl:param style="plain" name="start" path="$['start']"
                required="true"/>

    <wadl:param style="plain" name="next_collection_link"
                path="$['next_collection_link']">
      <wadl:link resource_type="#bugs-page-resource"/>
    </wadl:param>

    <wadl:param style="plain" name="prev_collection_link"
path="$['prev_collection_link']">
      <wadl:link resource_type="#bugs-page-resource"/>
    </wadl:param>

    <wadl:param style="plain" name="entries" path="$['entries']"
required="true"/>

    <wadl:param style="plain" name="entry_links"
                path="$['entries'][*]['self_link']">
      <wadl:link resource_type="%(root)s#bug"/>
    </wadl:param>
  </wadl:representation>
p
which defines the resource type and representation for the bugs
collection.

Note that the method doesn't reference the resource type.

When lazr.restfulclient makes this request it will check to see if the
response contains 'self_link', which it won't in this case. When it
isn't present it creates a WadlResource bound to the representation
declared in the wadl:response, namely bugs-page.

Now, when you go to resolve an attribute of that collection, total_size
say, it will call get_parameter on this created WadlResource, with an
explicit media_type. This will then call

  _find_representation_definition

which states:

     If this resource is bound to a representation, the most
     appropriate definition is the definition of that
     representation. Otherwise, the most appropriate definition is
     the definition of the representation served in response to a
     standard GET.

which is not what the implementation does. If media_type is not None
then it tries to look up the GET representation for that media_type,
which fails as it is not bound to the type.

Is the docstring correct and the code should be changed, or is there
another issue?

I don't have an easy reproducer script unfortunately.

Thanks,

James

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

Oh, here's a reproducer:

  lp.me.getBranches().total_size

Thanks,

James

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

Oh, interesting addendum, this is actually difficult to spot, as the above is
usually written as

  len(lp.me.getBranches())

where __len__ on a Collection is defined as

  def __len__(self):
     try:
        return int(self.total_size)
     except AttributeError:
        raise TypeError('collection size is not available')

presumably trying to catch the case where .total_size isn't an attribute provided
in the response.

When you access .total_size as above then you get

  AttributeError: 'NoneType' object has no attribute 'response'

so it is actually caught by the except block, and you don't notice that it is apparently
a code problem, rather than a limitation of the response.

Therefore I'm not sure that this has ever worked, but we just not have noticed for
this reason.

Thanks,

James

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

There are bug 274074 and bug 303414 which might be related to this bug

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

Yeah, this is exactly bug 274074 and it sounds like Leonard already knows
about the deeper issue.

Thanks,

James

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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