Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Request: Integer sizes / ranges / max value #36

Open
jleclanche opened this issue Jul 24, 2018 · 5 comments
Open

Request: Integer sizes / ranges / max value #36

jleclanche opened this issue Jul 24, 2018 · 5 comments
Labels

Comments

@jleclanche
Copy link

Along the lines of my previous requests, it'd be good to have the ranges of values for various definitions. For example:

                tax_percent:
                  description: A non-negative decimal (with at most four decimal places)
                    between 0 and 100. This represents the percentage of the subscription
                    invoice subtotal that will be calculated and added as tax to the
                    final amount in each billing period. For example, a plan which
                    charges $10/month with a `tax_percent` of `20.0` will charge $12
                    per invoice. To unset a previously-set value, pass an empty string.
                  nullable: true
                  type: number

This could have something like min_value:0 and max_value:100.

Another example:

        quantity:
          description: The usage quantity for the specified date.
          type: integer

I don't know whether to use an int32 or an int64 to store this. Would be useful to know.

Finally, there are 41 instances of type: number and 554 instances of type: integer in the spec. What's the difference between the two?

@jleclanche
Copy link
Author

Wait, is type: number actually a string representing a decimal number?

If so, wouldn't it make more sense to do something like type: string; format: decimal?

@brandur-stripe
Copy link
Contributor

Wait, is type: number actually a string representing a decimal number?

Not quite — it's a decimal but not a string.

See here for information on numeric types in JSON schema.

"Integers" are what you'd expect. "Numbers" are for any numeric type including floating point numbers.

@jleclanche
Copy link
Author

Right, that makes sense. My python instincts took over and yelled at me there's no way to accurately represent decimals without using strings. But of course JSON can :)

@richardm-stripe
Copy link
Contributor

Marking this as "future" as it's a good idea, but it's unclear when we would be able to action

@WesleyAC
Copy link

What is the blocker on taking action here? It seems like many items could easily have ranges added to them.

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

No branches or pull requests

4 participants