Support query errors in get_list

Review Request #5765 — Created May 2, 2014 and discarded

Information

Djblets
master
c3017e3...

Reviewers

Support query errors, with custom messages, in get_list.

All unit tests pass.

Description From Last Updated

Since this is a single line, it doesn't need the parens.

daviddavid

Mind putting this in an else: clause? It would make it more symmetric.

daviddavid

I wasn't terribly comfortable with this message handling, but I wasn't sure of a better way. The only alternative I …

MC mcote
MC
  1. 
      
  2. djblets/webapi/resources.py (Diff revision 1)
     
     
    Show all issues

    I wasn't terribly comfortable with this message handling, but I wasn't sure of a better way. The only alternative I could think of was some sort of new errors like PublishError/PUBLISH_ERROR that could easily take a custom message. Maybe a QueryError/QUERY_ERROR? Would that be better?

    1. This way of passing the message seems fine, but I'd like to better understand why you're making this change.

    2. It's all related to external user services, e.g. Bugzilla. My other changes to Review Board have allowed extensions to shuttle user queries off to an external service; however, there's no way to report errors back to the user. In particular, I'm concerned with a Bugzilla session expiring, which would silently cause user autocomplete to fail; in this case, I would want a helpful message to be displayed indicating that the user should log out and back in again to refresh thes session. This change allows us to return specific failures up to the client (I have a separate patch for Review Board to display these errors, which will be posted for review soon).

      Technically these errors don't really have to map to PERMISSION_DENIED, e.g. if Bugzilla is down. That's why I was wondering if there should be a generic 500 error for query failures. But I don't particularly care either way, since I can still return a specific error string.

    3. So where does the PermissionDenied exception come from? Are you raising that yourself?

      I'm thinking maybe instead of this very generic change to WebAPIResource, we might want to add more specific errors to the resources that can have extension-provided errors.

    4. It comes from my backend's overridden AuthBackend.query_users() method, raised up through the web API UserResource.get_queryset().

      Yeah, as I mentioned, I was thinking a QUERY_ERROR webapi.errors class (just realized we don't need a QueryError in another error class, since the error is originating from a WebAPIResource; that wasn't the case with the publish errors, which came from review model classes).

    5. Hm, although it wouldn't be quite as elegant since webapi.error classes aren't exceptions, so we'd have to look at the type of the object returned by WebAPIResource._get_query_set(), unless we did actually create a QueryError exception class as well. Just thinking out loud now. :)

  3. 
      
david
  1. 
      
  2. djblets/webapi/resources.py (Diff revision 1)
     
     
    Show all issues

    Since this is a single line, it doesn't need the parens.

  3. djblets/webapi/resources.py (Diff revision 1)
     
     
    Show all issues

    Mind putting this in an else: clause? It would make it more symmetric.

  4. 
      
MC
MC
MC
david
  1. I'm still not clear on your reasoning behind making a very generic addition to WebAPIResource instead of a specific addition to Review Board's UserResource.get_list.

    1. Ahh sorry I misunderstood. I'll give that a shot.

  2. 
      
MC
Review request changed
Status:
Discarded
Change Summary:
Better solution posted in review 5771.