Skip to content
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

Added GetRateLimits to MiscellaneousClient #848

Merged
merged 6 commits into from
Jul 27, 2015
Merged

Conversation

Red-Folder
Copy link
Contributor

Added support for the rate_limit API (https://developer.github.com/v3/rate_limit/). Note that this is the Miscellaneous API call - not the rate details returned as part of the headers for every API call. This functionality is referenced in #811

I'm interested in feedback (thus marked as WIP). Taken a couple of design decisions that may not fit with the overall solution:

  1. Created a separate ResourceRateLimit model rather than re-purpose the existing RateLimit. I've chosen to keep them separate as they have such different source (API vs Header) and could be changed by GitHub independently.
  2. Created a structure made up of MiscRateLimt/ ResourcesRateLimits/ ResourcesRateLimit using the Poco Json deserialization - fitting the API structure. Possibly better to perform custom deserialization (similar to ActivityPayload?) to return an array of a simple object (resource name, limit, remaining, reset). Note entirely sure of the names either.
  3. I've included the depreciating "Rate" for completeness. Given that it will depreciate, then maybe better to simply not get anyone into bad habits. Would be removed anyway if I go for custom deserialization.
  4. To utilize Poco Json deserialization I've created a reset (long) and resetAsDateTimeOffset. Better way to do? Again, if I go down custom deserialization then I can just use the reset as DateTimeOffset.

Feedback always welcomed.

@Red-Folder
Copy link
Contributor Author

Further thoughts on point 1;
If I re-purpose the existing RateLimit model then any consumer code doesn't need to handle the (logically) same data twice

namespace Octokit
{
[DebuggerDisplay("{DebuggerDisplay,nq}")]
public class MiscRateLimits
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We try to avoid abbreviations. So I'd call this MiscellaneousRateLimit

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed as suggested

@haacked
Copy link
Contributor

haacked commented Jul 24, 2015

If I re-purpose the existing RateLimit model then any consumer code doesn't need to handle the (logically) same data twice

Yeah, I don't think we're likely to change RateLimit in any way that would change them in one place, but not the other. As far as I can tell, they're the same type in the back-end. So I think re-using RateLimit and not introducing a new type is the way to go. 😄

Thanks for the contribution!

@Red-Folder
Copy link
Contributor Author

@haacked AppVeyor isn't building, is this because the original ResourceRateLimit.cs comment is still open, or is it something wrong with the code?

Originally I though it was the code - that I needed to put some #if !NETFX_CORE blocks round attributes. But I've made changes to that an it doesn't seem to make any change.

@shiftkey
Copy link
Member

@Red-Folder it looks like there's a merge conflict with this branch - AppVeyor should go green after that's been addressed.

@@ -396,7 +396,12 @@
<Compile Include="Exceptions\TwoFactorAuthorizationException.cs" />
<Compile Include="Http\HttpMessageHandlerFactory.cs" />
<Compile Include="Models\Response\TeamMembership.cs" />
<<<<<<< HEAD
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like these files need to be unified...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking into it now

@Red-Folder
Copy link
Contributor Author

Ok, green now. Now I leave it alone and get some sleep.

Lessons learnt this evening:

  1. Do a fetch & merge from upstream BEFORE pushing
  2. How to use Meld
  3. That I should double check everything is as I expect in the commit
  4. Run the automated tests (even after I make the smallest possible change that in no possible way could break the solution)
  5. I should have gone to bed about 2 hours ago. I'm too old to be up past midnight anymore

On a more serious note;

  • Appreciate the feedback & assistance given - please keep it coming.
  • I still need to run the integration tests (for some reason I cant make run yet - keep getting bad credentials)

@shiftkey
Copy link
Member

@Red-Folder given this is a new feature (and the test is written) I'm happy to take it in as-is.

Don't stress too much about running the integration tests, it's certainly the toughest part of contributing (and something I need to revisit).

var result = await client.GetRateLimits();

// Test the high level object
Assert.NotNull(result);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I love the explicitness here, I think letting this fall through to the Assert.Equals is totally fine to simplify the tests...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to clarify, is this the NotNull check? What about the other NotNull tests further down - lose them as well to make more readable?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assumed the above was yes & yes

@shiftkey shiftkey changed the title [WIP] Added GetRateLimits to MiscellaneousClient Added GetRateLimits to MiscellaneousClient Jul 26, 2015

namespace Octokit
{
#if !NETFX_CORE
[Serializable]
[DebuggerDisplay("{DebuggerDisplay,nq}")]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this can live outside the #if

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do. I changed all this when I thought it was causing the appveyor problems (there was reasoning behind my thinking but I won't bore you)

haacked added a commit that referenced this pull request Jul 27, 2015
Added GetRateLimits to MiscellaneousClient
@haacked haacked merged commit a7bc09e into octokit:master Jul 27, 2015
@haacked
Copy link
Contributor

haacked commented Jul 27, 2015

Thanks for your contribution!

selfie-0

@Red-Folder Red-Folder mentioned this pull request Jul 29, 2015
@Red-Folder
Copy link
Contributor Author

Is it wrong that after 20+ years in IT, I'm seeing a 6 second vine from Phil Hacck as my most glowing accreditation?

Surely there must be a "thumbs up" accreditation section somewhere in Linkedin .... off to go look

@haacked
Copy link
Contributor

haacked commented Aug 3, 2015

Surely there must be a "thumbs up" accreditation section somewhere in Linkedin .... off to go look

LOL! It's a GitHub special accreditation. Much better than LinkedIn.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants