-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Access to the last ApiInfo object #855
Conversation
/// <summary> | ||
/// Provides a property for the Last recorded API infomation | ||
/// </summary> | ||
public interface IApiInfo |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sounds like an interface for the ApiInfo
itself. What about IApiInfoProvider
, it seems to be more in line with the comments as well?
@Red-Folder I sent you a PR at Red-Folder#1, I still haven't addressed the threading issue, though. |
@khellang Great stuff. I'll pull in over the weekend |
Can anyone recommend a good Api call to use for the integration test? I'm current using the Rate Limit call - but this doesn't include links, oauth scope, accepted oauth scope, & etag,in the ApiInfo. I'd like an Api call which will populate all of these for testing |
@Red-Folder I'd suggest a couple of calls:
|
} | ||
private ApiInfo _lastApiInfo; | ||
private readonly object LastApiInfoLocker = new object(); | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@khellang I've added this for the thread safety. Thoughts welcome
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, do we actually need locks here? If someone is reading the value just as another thread is writing the value, it sort of doesn't matter who wins. After all, the read value will only be slightly outdated.
In other words, I don't see any problems with race conditions in this case as this isn't data that's timing sensitive. I don't think torn reads are a problem because these are 32 bit references.
This value is going to be set on every request, I'd rather avoid a lock here unless it's absolutely needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been taking the Benevolent Dictator role. 😛
I'd like to hear from @khellang if there are specific concerns with removing the locks. If not, let's remove them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Off topic)
Please tell me someone out there is photoshoping the below - replacing with @haacked and the Octocat (not saying which way round)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's fine to remove the locks, it's probably a bit too much. I just brought it up because there's now some shared, mutable state going on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Let's remove the locks, but make sure we comment it and explain why so if someone else comes along, they understand why there's shared mutable state.
Also, one idea we should do is to set LastApiInfo
to a copy of the ApiInfo
to reduce the sharing of mutable state. In fact, I think LastApiInfo
should be a method GetLastApiInfo
and it should always return a copy of the last ApiInfo
That way, Octokit is in control of the lifetime of that object and a consumer can't inadvertently keep the object around longer than expected. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM 👍
@shiftkey Added further integration tests now - seems to cover all bases if a little repetitive. I've added a new test attribute for Personal Access Token - the OAuth/ AcceptedOAuth test uses that attribute. |
Hi guys, any further feedback on this one? I'm in danger of losing my dev environment in the next few days so would like to get this PR boxed off. Thanks |
// Seem to have to do this to pass a whole bunch of tests (for example Octokit.Tests.Clients.EventsClientTests.DeserializesCommitCommentEventCorrectly) | ||
// I believe this has something to do with the Mocking framework. | ||
if (this == null || this.Links == null || this.OauthScopes == null || this.RateLimit == null || this.Etag == null) | ||
return null; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extra points for explaining why I needed to add this null check. For some reason bundles of tests fail without it (comment and see what happens). I think it is something to do with how the mocking framework is handling the object - but can't understand why it touches it.
Could someone have a look over my cloning logic. Seems to work - but I could do with a fresh set of eyes on it. Note that I'm having to do new String(originalString.ToCharArray()) as nothing else (string.Copy for example) seems to work with portable version. |
{ | ||
// Seem to have to do this to pass a whole bunch of tests (for example Octokit.Tests.Clients.EventsClientTests.DeserializesCommitCommentEventCorrectly) | ||
// I believe this has something to do with the Mocking framework. | ||
if (this == null || this.Links == null || this.OauthScopes == null || this.RateLimit == null || this.Etag == null) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When would this
be null though?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair point.
I really not sure why I need this line at all - but something blew up within the mocking framework so I added everything and kitchen sink.
Maybe went a tad overboard ;)
Looks good. The title suggests this is a WIP. Is that still the case or is this good to merge? |
@haacked Sorry Phil, I'd not been chasing this. I'd lost my dev environment & between jobs (must find new job before wife makes me paint more fences). Dev environment back up and running. Will make the two minor tweaks you mention above then should be good to merge. Probably today or tomorrow |
@Red-Folder No problem! Thanks for continuing to work on this and good luck finding a new job! |
Pops head above the parapet ... "Looks good to go" (Prepares to duck back down quickly) |
Access to the last ApiInfo object
Ah ... excellent. A second thumbs up to add to the collection. I've added a whole section on my bio page for them ;) http://www.red-folder.com/Home/MyBio (then scroll down). One day I'll setup the anchors, make the site size correctly, finish it, etc, etc, blah, blah |
As discussed in issue #504
Allows the user to get the contents of the last ApiInfo (so last Api call). Provided as a property of GitHubClient which calls a property of Connection then a property of HttpClientAdapter.
The most obvious use for it is to check the current rate limit without making a separate API call.
Two concerns for me:
Thanks