-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Bigtable: TimestampRanges must be milliseconds granularity #5002
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
Bigtable: TimestampRanges must be milliseconds granularity #5002
Conversation
|
I'm not familiar with how Bigtable handles timestamps. @mbrukman might? |
|
oh. Here's some related info also bigtable support for microseconds |
|
I'm going to make the executive decision. This is for row range filters. For now, start out to be rounded down to nearest ms, and end needs to be rounded up to the nearest ms. If and when Cloud Bigtable opts to enable microsecond support, which is not on the near term roadmap, we'll have to do a sweep of all clients for behavior like this. |
| if self.end is not None: | ||
| timestamp_range_kwargs['end_timestamp_micros'] = ( | ||
| _microseconds_from_datetime(self.end)) | ||
| _microseconds_from_datetime(self.end) // 1000 * 1000) |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
| end = None | ||
| if end_micros is not None: | ||
| end = _EPOCH + datetime.timedelta(microseconds=end_micros) | ||
| pb_kwargs['end_timestamp_micros'] = end_micros |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
8e31bd5 to
508e40f
Compare
508e40f to
edd9ce1
Compare
edd9ce1 to
abf1d79
Compare
|
@tswast yeah, stupid mistake. I changed the tests to better capture what it should do. |
Closes #4932.
But. @tswast Should we have this and change it if/when BigTable supports microseconds or should we have the users handle it themselves and just document?