Skip to content

Conversation

sherrardb
Copy link
Collaborator

allow users to specify the API version when creating a new Net::Stripe object, per https://stripe.com/docs/api#versioning

Copy link
Collaborator

@andrewsolomon andrewsolomon left a comment

Choose a reason for hiding this comment

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

Apart from the few tweaks suggested, it looks good to me!

my $api_version = defined( $self->api_version ) ? $self->api_version : $self->_get_account_api_version();

my @api_version = split( '-', $api_version );
my $api_version_dt = eval {
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think this pattern is a bit risky in case the internals produce a list. I'd say it's safer to do:

my $api_version_dt;
eval {
    $api_version_dt  = DateTime->new(...);
};

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

will adjust and revert.

die Net::Stripe::Error->new(
type => "API version validation error",
message => $message,
) unless Scalar::Util::blessed( $api_version_dt ) && $api_version_dt->isa( 'DateTime' );
Copy link
Collaborator

Choose a reason for hiding this comment

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

DateTime is pretty strict and dies when the code at line 1736 doesn't produce a DateTime object, so I don't think you need this code. Unless there's a case you've found that it's necessary?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

i do not have an actual use case. i am a belt-and-suspenders kind of guy. :-)


use constant UNSUPPORTED_API_VERSION_PRE => '2012-09-24'; # valid API version, but less than min supported
use constant MIN_API_VERSION => '2012-10-26';
use constant INVALID_API_VERSION => '2012-10-27'; # valid date within range, but invalid API version
Copy link
Collaborator

Choose a reason for hiding this comment

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

INVALID_API_VERSION is only for testing, so I think it should be defined in the test script. Same for UNSUPPORTED_API_VERSION_PRE and UNSUPPORTED_API_VERSION_POST

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

good catch. will fix and revert.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

any preference as to use constant vs my for these values within the test script?

also, a note as to the original reasoning for placement in Net::Stripe::Constants: even though not strictly necessary, the process of maintaining/updating these values, since they are all relative to one another, is eased by having them all in one place for easy visual comparison.
ie, as you update MIN_API_VERSION, you change UNSUPPORTED_API_VERSION_PRE to the previous value of MAX_API_VERSION, and you update INVALID_API_VERSION to the next calendar date after MIN_API_VERSION...

@sherrardb
Copy link
Collaborator Author

updates are ready for review

 * allow users to specify the API version when creating a new Net::Stripe object, per <https://stripe.com/docs/api/versioning#versioning>
 * add api_version argument and method for Net::Stripe object
 * add force_api_version argument and method for Net::Stripe object
 * update POD
 * closes <lukec#80> and <lukec#127>
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.

2 participants