launchpad-dev team mailing list archive

[James Westby <jw+debian@xxxxxxxxxxxxxxx>]

On Tue, 02 Mar 2010 17:48:52 +0000, James Westby <jw+debian@xxxxxxxxxxxxxxx> wrote:
> On Tue, 2 Mar 2010 11:23:46 -0600, Deryck Hodge <deryck.hodge@xxxxxxxxxxxxx> wrote:
> > I wonder if read_only does this or could be made to do this?  I asked
> > Leonard on IRC and he wasn't sure.  He's also very busy at the moment
> > to dig further into the question.
> 
> It appears like a one-line change to lazr.restful would change this for
> read-only attributes.

But yes, thinking about this more, it would be a bad idea.

Consider (to stick with bugs, but it's not unique to that app):

  print bug.users_affected_count
  bug.markUserAffected(lp.me)
  print bug.users_affected_count

if we want this to print two different numbers we need to include that
(read-only) attribute in the etag calculation.

Here's why:

  when we fetch the bug we get told an etag for it based on the current
  values

  We then call a method that alters the bug, marking it as affecting
  someone new.

  When this method finishes it will trigger a refresh of the local
  object so that we can be up to date.

  That refresh is done with a conditional get, sending If-None-Match:
  and the etag we got to start with.

If the users_affected_count is not included in the etag calculation then
the conditional get will give a 304 and we will have stale information
locally.

Therefore we can't do this across the board, and only allow marking
specific attributes as volatile. I'm not entirely sure what the criteria
would be yet:

  * read-only
  * not affected by any methods that can be called on the object either
    (not the same thing in lazr.restful)

but this is quite hard to get right. The right criteria may be that it
is unlikely to cause issues if the user has an outdated value.

Thanks,

James