Parse more values to appropriate types

[philippeitis]

Certain values don't currently use the appropriate types as described by the schema - it seems that due to JSON limitations, Google might use strings to encode numbers - a few examples below, taken from the drive-api.json file:

"version": {
    "description": "A monotonically increasing version number for the file. This reflects every change made to the file on the server, even those not visible to the user.",
    "format": "int64",
    "type": "string"
}

"durationMillis": {
    "description": "The duration of the video in milliseconds.",
    "format": "int64",
    "type": "string"
}

"size": {
    "description": "The size of the revision's content in bytes. This is only applicable to files with binary content in Drive.",
    "format": "int64",
    "type": "string"
}

This results in me having to write code like this:

let size = u64::from_str(&file.size.unwrap()).unwrap();

Even though the file size is known to be an integer, and it should really be parsed by the API.

This seems to be due to this map:

google-apis-rs/src/generator/lib/util.py

Line 22 in 93c8601

TYPE_MAP = {'boolean' : 'bool',

And this block of code:

google-apis-rs/src/generator/lib/util.py

Line 380 in 93c8601

try:

I think the fix would be to default to using the format specifier first, falling back to the type specifier if the format is not present / supported.

However, this would require a breaking change, so I want to ask about how this should be handled before making any changes.

It would also be nice to support "date-time" format values, but that would require pulling in additional dependencies, which may not be desirable. I think it would be nice to provide base64 decoding / encoding for "byte" format values, to ensure that those values are constructed correctly.

All of the unsupported formats I found:

• google-duration
• byte
• google-datetime
• date-time
• google-fieldmask
• date

[Byron]

Thanks a lot for bringing this up! I remember having left the type-system to be just barely good enough to be acceptable for the use-case I had back then, and agree that improvements are desirable and possible.

However, this would require a breaking change, so I want to ask about how this should be handled before making any changes.

I am absolutely open to that, it seems to be a worthy cause. Even though the version number was incremented to 4.0 not too long ago, the crates have not actually been republished. By going to 5.0 it would mean people have to deal with a couple of additional breaking changes, which I think is probably worth it for them if they consider the upgrade in the first place.

It would also be nice to support "date-time" format values, but that would require pulling in additional dependencies, which may not be desirable. I think it would be nice to provide base64 decoding / encoding for "byte" format values, to ensure that those values are constructed correctly.

I definitely wouldn't mind, and rather throw CPU time at a problem than human time. If there is high demand, a feature toggle could be added later to avoid those newly added dependencies.

A PR with such an improvement is definitely welcome.