On 7 July 2011 06:51, Rodney Dawes <email address hidden> wrote:
> It is not launchpadlib, but lazr.restfulclient that is doing the
> comparison. And it's comparing self_link, http_etag, and an internal
> dirty dict it keeps around. The only differing point is the http_etag in
> that comparison. I am aware of the workarounds, but they are
> workarounds. If lazr.restfulclient is going to offer an __eq__ to
> compare the objects with, then it should work reliably. And if Launchpad
> is going to give me a person resource, for a specific user, that
> resource should be the same, no matter where it is pulled from.
I sympathize, but making sure there's no more than one local proxy
object for any remote object can be a hard problem. In general I
don't think lazr/lplib solves that problem perfectly; at least I have
seen other cases where they get out of sync. (For instance, iirc,
when objects are returned from a collection.) It's reasonable to me
that lplib would interpret eq as "objects are identical" rather than
"objects refer to the same remote object"; perhaps it's even more
reasonable. If that's true, then comparing the URLs is not a
workaround but in fact the correct client behaviour.
So I think to start with lplib needs to document how it promises this
should work.
On 7 July 2011 06:51, Rodney Dawes <email address hidden> wrote:
> It is not launchpadlib, but lazr.restfulclient that is doing the
> comparison. And it's comparing self_link, http_etag, and an internal
> dirty dict it keeps around. The only differing point is the http_etag in
> that comparison. I am aware of the workarounds, but they are
> workarounds. If lazr.restfulclient is going to offer an __eq__ to
> compare the objects with, then it should work reliably. And if Launchpad
> is going to give me a person resource, for a specific user, that
> resource should be the same, no matter where it is pulled from.
I sympathize, but making sure there's no more than one local proxy
object for any remote object can be a hard problem. In general I
don't think lazr/lplib solves that problem perfectly; at least I have
seen other cases where they get out of sync. (For instance, iirc,
when objects are returned from a collection.) It's reasonable to me
that lplib would interpret eq as "objects are identical" rather than
"objects refer to the same remote object"; perhaps it's even more
reasonable. If that's true, then comparing the URLs is not a
workaround but in fact the correct client behaviour.
So I think to start with lplib needs to document how it promises this
should work.