You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: clients/google-api-services-bigtableadmin/v2/2.0.0/com/google/api/services/bigtableadmin/v2/model/GoogleBigtableAdminV2TypeStringEncoding.java
+24Lines changed: 24 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -37,6 +37,13 @@ public final class GoogleBigtableAdminV2TypeStringEncoding extends com.google.ap
Copy file name to clipboardExpand all lines: clients/google-api-services-bigtableadmin/v2/2.0.0/com/google/api/services/bigtableadmin/v2/model/Type.java
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -25,8 +25,8 @@
25
25
* consistently with the original typed value? Note that Bigtable will always sort data based on the
26
26
* raw encoded value, *not* the decoded type. - Example: BYTES values sort in the same order as
27
27
* their raw encodings. - Counterexample: Encoding INT64 as a fixed-width decimal string does *not*
28
-
* preserve sort order when dealing with negative numbers. INT64(1) > INT64(-1), but
29
-
* STRING("-00001") > STRING("00001). * Self-delimiting: If we concatenate two encoded values, can
28
+
* preserve sort order when dealing with negative numbers. `INT64(1) > INT64(-1)`, but
29
+
* `STRING("-00001") > STRING("00001)`. * Self-delimiting: If we concatenate two encoded values, can
30
30
* we always tell where the first one ends and the second one begins? - Example: If we encode INT64s
31
31
* to fixed-width STRINGs, the first value will always contain exactly N digits, possibly preceded
32
32
* by a sign. - Counterexample: If we concatenate two UTF-8 encoded STRINGs, we have no way to tell
0 commit comments