-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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: Allow microseconds for TimestampRangeFilter (again) #5931
Comments
Hi @telpirion can we get traction on this issue? Thanks in advance! |
Hello @telpirion kindly reminder about this issue. |
This is affecting my project as well. Thanks for the fix @mmetto! |
@telpirion @igorbernstein2 can I get your eyes on the linked PR? This is blocking our testing and requires manual changes to get the tests working properly with newest bigtable client/models locally, while also locking us to use old version of dependencies for our service. |
This obscure error has caused me some issues too. |
@telpirion @igorbernstein2 any chance we can get traction on this issue? |
Closing as the Bigtable service behaves similarly to the emulator. |
Is your feature request related to a problem? Please describe.
Could you please remove code rejecting microseconds when defining
TimestampRangeFilter
s?Describe the solution you'd like
Describe alternatives you've considered
Detect which API version is used (v1 vs. v2) and deny or allow microseconds for
TimestampRangeFilter
accordingly.Additional context
It seems v2 APIs/clients use microseconds now when defining
TimestampRangeFilter
s. This breaks most tests we have after upgrading gcp packages to get our dev environments working on Mac M1.The v2 proto defines TimestampFilter using micros:
and here is
Filters.java
coming fromcom.google.cloud.bigtable.data.v2.models
package:The text was updated successfully, but these errors were encountered: