Update virtual_person_id type to uint64. #56
Conversation
Currently the population_offset and total_population in VirtualPersonPool are uint64, while virtual_person_id in VirtualPersonActivity is int64. This could cause an issue when the range covered by virtual person pools is out of range of int64. This is a safe change per https://developers.google.com/protocol-buffers/docs/proto#updating
There was a problem hiding this comment.
this requires that you change all the upstream builds as well? I'm assuming this will cause problems in an EDP uses an old version of virtual-people-common?
Reviewed 1 of 1 files at r1, all commit messages.
Reviewable status:complete! all files reviewed, all discussions resolved (waiting on @tcsnfkx and @wangyaopw)
There was a problem hiding this comment.
Reviewed 1 of 1 files at r1, all commit messages.
Reviewable status:
There was a problem hiding this comment.
Per https://developers.google.com/protocol-buffers/docs/proto#updating:
int32, uint32, int64, uint64, and bool are all compatible – this means you can change a field from one of these types to another without breaking forwards- or backwards-compatibility. If a number is parsed from the wire which doesn't fit in the corresponding type, you will get the same effect as if you had cast the number to that type in C++ (for example, if a 64-bit number is read as an int32, it will be truncated to 32 bits).
So I think it wouldn't cause issue unless a model use population pool with id range > int64.max_value
Reviewable status:
There was a problem hiding this comment.
Reviewed 1 of 1 files at r1, all commit messages.
Reviewable status:
Currently the population_offset and total_population in VirtualPersonPool are uint64, while virtual_person_id in VirtualPersonActivity is int64. This could cause an issue when the range covered by virtual person pools is out of range of int64.
Update virtual_person_id type to uint64.
This is a safe change per https://developers.google.com/protocol-buffers/docs/proto#updating
This change is