1. 30 Jun, 2017 1 commit
    • antirez's avatar
      Added GEORADIUS(BYMEMBER)_RO variants for read-only operations. · f8547e53
      antirez authored
      Issue #4084 shows how for a design error, GEORADIUS is a write command
      because of the STORE option. Because of this it does not work
      on readonly slaves, gets redirected to masters in Redis Cluster even
      when the connection is in READONLY mode and so forth.
      
      To break backward compatibility at this stage, with Redis 4.0 to be in
      advanced RC state, is problematic for the user base. The API can be
      fixed into the unstable branch soon if we'll decide to do so in order to
      be more consistent, and reease Redis 5.0 with this incompatibility in
      the future. This is still unclear.
      
      However, the ability to scale GEO queries in slaves easily is too
      important so this commit adds two read-only variants to the GEORADIUS
      and GEORADIUSBYMEMBER command: GEORADIUS_RO and GEORADIUSBYMEMBER_RO.
      The commands are exactly as the original commands, but they do not
      accept the STORE and STOREDIST options.
      f8547e53
  2. 20 Dec, 2016 2 commits
    • antirez's avatar
      Geo: fix GEOHASH return value for consistency. · 0f722570
      antirez authored
      The same thing observed in #3551 by gnethercutt also fixed for
      GEOHASH as the original PR did.
      0f722570
    • antirez's avatar
      Geo: fix edge case return values for uniformity. · 913070a9
      antirez authored
      There were two cases outlined in issue #3512 and PR #3551 where
      the Geo API returned unexpected results: empty strings where NULL
      replies were expected, or a single null reply where an array was
      expected. This violates the Redis principle that Redis replies for
      existing keys or elements should be indistinguishable.
      
      This is technically an API breakage so will be merged only into 4.0 and
      specified in the changelog in the list of breaking compatibilities, even
      if it is not very likely that actual code will be affected, hopefully,
      since with the past behavior basically there was to acconut for *both*
      the possibilities, and the new behavior is always one of the two, but
      in a consistent way.
      913070a9
  3. 05 Dec, 2016 1 commit
    • antirez's avatar
      Geo: fix computation of bounding box. · 001138ae
      antirez authored
      A bug was reported in the context in issue #3631. The root cause of the
      bug was that certain neighbor boxes were zeroed after the "inside the
      bounding box or not" check, simply because the bounding box computation
      function was wrong.
      
      A few debugging infos where enhanced and moved in other parts of the
      code. A check to avoid steps=0 was added, but is unrelated to this
      issue and I did not verified it was an actual bug in practice.
      001138ae
  4. 27 Jul, 2016 1 commit
    • antirez's avatar
      Multiple GEORADIUS bugs fixed. · 356a6304
      antirez authored
      By grepping the continuous integration errors log a number of GEORADIUS
      tests failures were detected.
      
      Fortunately when a GEORADIUS failure happens, the test suite logs enough
      information in order to reproduce the problem: the PRNG seed,
      coordinates and radius of the query.
      
      By reproducing the issues, three different bugs were discovered and
      fixed in this commit. This commit also improves the already good
      reporting of the fuzzer and adds the failure vectors as regression
      tests.
      
      The issues found:
      
      1. We need larger squares around the poles in order to cover the area
      requested by the user. There were already checks in order to use a
      smaller step (larger squares) but the limit set (+/- 67 degrees) is not
      enough in certain edge cases, so 66 is used now.
      
      2. Even near the equator, when the search area center is very near the
      edge of the square, the north, south, west or ovest square may not be
      able to fully cover the specified radius. Now a test is performed at the
      edge of the initial guessed search area, and larger squares are used in
      case the test fails.
      
      3. Because of rounding errors between Redis and Tcl, sometimes the test
      signaled false positives. This is now addressed.
      
      Whenever possible the original code was improved a bit in other ways. A
      debugging example stanza was added in order to make the next debugging
      session simpler when the next bug is found.
      356a6304
  5. 23 May, 2016 1 commit
  6. 09 May, 2016 1 commit
  7. 04 May, 2016 1 commit
  8. 18 Feb, 2016 4 commits
  9. 07 Oct, 2015 1 commit
    • antirez's avatar
      Fix extractLongLatOrReply() sanity check conditionals. · f29e3848
      antirez authored
      the check for lat/long valid ranges were performed inside the for loop,
      two times instead of one, and the first time when the second element of
      the array, xy[1], was yet not populated. This resulted into issue #2799.
      
      Close issue #2799.
      f29e3848
  10. 06 Oct, 2015 1 commit
  11. 01 Oct, 2015 1 commit
  12. 14 Sep, 2015 1 commit
    • antirez's avatar
      GEORADIUS: Don't report duplicates when radius is huge. · 3c23b5ff
      antirez authored
      Georadius works by computing the center + neighbors squares covering all
      the area of the specified position and radius. Then a distance filter is
      used to remove elements which are actually outside the range.
      
      When a huge radius is used, like 5000 km or more, adjacent neighbors may
      collide and be the same, leading to the reporting of the same element
      multiple times. This only happens in the edge case of huge radius but is
      not ideal.
      
      A robust but slow solution would involve qsorting the range to remove
      all the duplicates. However since the collisions are only in adjacent
      boxes, for the way they are ordered in the code, it is much faster to
      just check if the current box is the same as the previous one processed.
      
      This commit adds a regression test for the bug.
      
      Fixes #2767.
      3c23b5ff
  13. 26 Jul, 2015 3 commits
  14. 09 Jul, 2015 2 commits
    • antirez's avatar
      GEOENCODE / GEODECODE commands removed. · b96af595
      antirez authored
      Rationale:
      
      1. The commands look like internals exposed without a real strong use
      case.
      2. Whatever there is an use case, the client would implement the
      commands client side instead of paying RTT just to use a simple to
      reimplement library.
      3. They add complexity to an otherwise quite straightforward API.
      
      So for now KILLED ;-)
      b96af595
    • antirez's avatar
      Geo: -Ofast breaks builds on older GCCs. · 1e127842
      antirez authored
      1e127842
  15. 06 Jul, 2015 1 commit
  16. 01 Jul, 2015 1 commit
  17. 29 Jun, 2015 12 commits
  18. 27 Jun, 2015 3 commits
  19. 26 Jun, 2015 1 commit
    • antirez's avatar
      Geo: from lat,lon API to lon,lat API according to GIS standard · fa9d62d3
      antirez authored
      The GIS standard and all the major DBs implementing GIS related
      functions take coordinates as x,y that is longitude,latitude.
      It was a bad start for Redis to do things differently, so even if this
      means that existing users of the Geo module will be required to change
      their code, Redis now conforms to the standard.
      
      Usually Redis is very backward compatible, but this is not an exception
      to this rule, since this is the first Geo implementation entering the
      official Redis source code. It is not wise to try to be backward
      compatible with code forks... :-)
      
      Close #2637.
      fa9d62d3
  20. 24 Jun, 2015 1 commit