Sorting by map-like values

[MMcM]

message Item {
  optional int64 rec_no = 1 [(field).primary_key = true];
  optional string color = 2;
  message PriceMap {
    message Entry {
      optional string key = 1;
      optional int32 value = 2;
    }
    repeated Entry map_value = 1;
  }
  optional PriceMap prices = 3;
}

...
        final RecordMetaDataHook hook = md -> {
            md.addIndex("Item", "color_price",  Key.Expressions.concat(
                    Key.Expressions.field("color"),
                    Key.Expressions.field("prices").nest(Key.Expressions.mapKeyValues("map_value"))));
        };
...
        RecordQuery query = RecordQuery.newBuilder()
                .setRecordType("Item")
                .setFilter(Query.and(
                        Query.field("color").equalsValue("red"),
                        Query.field("prices").matches(Query.field("map_value")
                                .mapMatches(k -> k.equalsValue("large"), null))))
                .setSort(Key.Expressions.field("prices").nest(Key.Expressions.mapValues("map_value")))
                .build();

The query is not very robustly expressed, but the idea is something like

SELECT * FROM Item WHERE color = 'red' ORDER BY prices['large']

The immediate problem is that RecordQueryPlanner.AndWithThenPlanner.planNestedFieldChild is not able to advanceCurrentSort when it is only a part of a nested concat that just passed the conditional check.

But, in general, all of currentSortMatches has problems with multi-column keys.

For instance, adding another condition

                                .mapMatches(k -> k.equalsValue("large"), v -> v.greaterThan(100)))))

further restricts where the sort must match because it is an inequality.

In this more complex case, RecordQueryPlanner.AndWithThenPlanner.plan is called recursively due to the nested conjunction. The inner one does advance the sort, but fails to successfully convey this to the outer one.