Add store test case for GeoRadiusByMember

[azuredream]

#1548

[azuredream]

Hi @romange , I've added two use cases for STORE and STOREDIST. They store the query result(with hash or dist) into a key(zset).
Similarly, GEOSEARCHSTORE, GEORADIUS also support this.

[romange]

@azuredream sure, I will take a look. Meanwhile please see https://redis.io/commands/geosearch/ examples.
they do not work because the distance units parsing is case sensitive. Would you like to fix it?
And, if you do - please see if CmdArgParser class can simplify the parsing code (I forgot it was introduced lately).
See #2148 (comment) for example on how it can help.

[azuredream]

Thanks. I'll fix it.

[romange]

@azuredream I think I fixed the transactional code to support GEORADIUSBYMEMBER.
The command code must be changed though. It should become a two-hop operation similarly to ZInterStore for example

[romange]

of course you need two hops only if the STORE option exist, otherwise you proceed like today.

[azuredream]

Thanks, I'll update my code accordingly.
Please note that in GEOSEARCHSTORE, the destination is not the last key.
GEOSEARCHSTORE destination source <FROMMEMBER member |
FROMLONLAT longitude latitude> <BYRADIUS radius <M | KM | FT | MI>
| BYBOX width height <M | KM | FT | MI>> [ASC | DESC] [COUNT count
[ANY]] [STOREDIST]

[azuredream]

Hi Romange,
PR updated.
I encountered a wired issue. This command works in CLI:
127.0.0.1:6379> GEORADIUSBYMEMBER Europe Madrid 700 KM STORE test1
(integer) 2
(15.54s)
127.0.0.1:6379> zrange test1 0 -1

1. "Madrid"
2. "Lisbon"

The first unit test case worked as well.
GEORADIUSBYMEMBER Europe Madrid 700 KM WITHCOORD WITHDIST

However, the second test case failed. Please note that this command worked in CLI.
GEORADIUSBYMEMBER Europe Madrid 700 KM STORE store_key
[ RUN ] ZSetFamilyTest.GeoRadiusByMember
get resp: ERR Member not found
F20231114 21:37:55.006270 2607605 test_utils.cc:466] Check failed: RespExpr::STRING == int(resp.type) (0 vs. 6) [GEORADIUSBYMEMBER, Europe, Madrid, 700, KM, STORE, store_key]

When I used GDB to run the test case line by line, it worked again.

I suppose it's something to do with the schedule-execute model.
When I use STORE option, there will be 3 transactions while 2 without STORE.
It's confusing to me that the test case failed at the first transaction (get key from db), not the last one.
I'd appreciate it if you could share your thought on this. Thanks!

[romange]

Hello @azuredream , thank you for continuing working on this. Can you please try rebasing the branch and fixing the conflicts?

[azuredream]

I'll reopen a new PR based on the latest main.