chore(test): Add test to verify that query ranges work as expected

[igorbernstein2]

No description provided.

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (master@9e693b4). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #445   +/-   ##
=========================================
  Coverage          ?   80.63%           
  Complexity        ?     1115           
=========================================
  Files             ?      105           
  Lines             ?     6941           
  Branches          ?      369           
=========================================
  Hits              ?     5597           
  Misses            ?     1146           
  Partials          ?      198           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9e693b4...30db5c2. Read the comment docs.

[ghost]

Hi Igor,
Rohan Ramnarine asked me to add some data to help reproduce the issue I'm running into where the CLOSED end range data is not being returned. Here is the integration test that reproduces the issue I'm seeing using the same row key data we have in BigTable and the range key format we use when querying using the client.

  @Test
  public void rangeQueries2() {
    BigtableDataClient client = testEnvRule.env().getDataClient();
    String tableId = testEnvRule.env().getTableId();
    String familyId = testEnvRule.env().getFamilyId();
    String startRange = "login|9223370437392774807";
    String endRange = "login|9223370437392775807";

    String keyA = "login|9223370437392775807|uniqueaa-4bff-44e4-8f55-241f733f8ae";
    String keyZ = "login|9223370437392775807|uniqueda-f31a-4f16-b1ed-c90288d68d62";

    long timestampMicros = System.currentTimeMillis() * 1_000;

    client.bulkMutateRows(
            BulkMutation.create(tableId)
                    .add(RowMutationEntry.create(keyA).setCell(familyId, "", timestampMicros, "A"))
                    .add(RowMutationEntry.create(keyZ).setCell(familyId, "", timestampMicros, "Z")));

    Row expectedRowA =
            Row.create(
                    ByteString.copyFromUtf8(keyA),
                    ImmutableList.of(
                            RowCell.create(
                                    testEnvRule.env().getFamilyId(),
                                    ByteString.copyFromUtf8(""),
                                    timestampMicros,
                                    ImmutableList.<String>of(),
                                    ByteString.copyFromUtf8("A"))));

    Row expectedRowZ =
            Row.create(
                    ByteString.copyFromUtf8(keyZ),
                    ImmutableList.of(
                            RowCell.create(
                                    testEnvRule.env().getFamilyId(),
                                    ByteString.copyFromUtf8(""),
                                    timestampMicros,
                                    ImmutableList.<String>of(),
                                    ByteString.copyFromUtf8("Z"))));

    // Closed/Closed
    assertThat(
            ImmutableList.copyOf(
                    client.readRows(
                            Query.create(tableId)
                                    .range(ByteStringRange.unbounded().startClosed(startRange).endClosed(endRange)))))
            .containsExactly(expectedRowA, expectedRowZ);
  }

[igorbernstein2]

Thanks for putting together the example. However that test failure is expected.
The range [login|9223370437392774807, login|9223370437392775807] does not include the key login|9223370437392775807|uniqueda-f31a-4f16-b1ed-c90288d68d62.

This is because, lexicographically, prefix will always come before prefixSuffix.

[ghost]

Is there a way to construct the end range in the query such that it matches any row key containing that prefix? The login|<reverse timestamp> is all that we have and the unique id suffix is not known. The only thing I've seen work so far is to change the reverse timestamp itself e.g. use 9223370437392775808

[igorbernstein2]

ByteStringRange has a method called prefix which constructs a range that includes all keys with the supplied prefix. So you can do something like:

ByteStringRange startRange = ByteStringRange.prefix(....);
ByteStringRange endRange = ByteStringRange.prefix(....);

Preconditions.checkState(startRange.getStartBound() == BoundType.CLOSED);
Preconditions.checkState(endRange.getEndBound() == BoundType.OPEN);

ByteStringRange combinedRange = ByteStringRange.create(startRange.getStart(), endRange.getEnd());

If you have the inclination, I would also appreciate a PR to add a utility method ByteStringRange ByteStringRange#getBound(ByteStringRange ranges...). The implementation would do something similar to RowSetUtil#getBound(). Or something else along those lines that would let you compose 2 prefix ranges