diff --git a/Dockerfile b/Dockerfile index bf0c674be..931f30d59 100644 --- a/Dockerfile +++ b/Dockerfile @@ -4,7 +4,7 @@ FROM ubuntu:18.04 RUN apt-get update \ && DEBIAN_FRONTEND=noninteractive apt-get install -qqy \ - build-essential nasm autotools-dev autoconf libjemalloc-dev tcl tcl-dev uuid-dev \ + build-essential nasm autotools-dev autoconf libcurl4-openssl-dev libjemalloc-dev tcl tcl-dev uuid-dev \ && apt-get clean CMD make diff --git a/README.md b/README.md index 18db3c875..538aaf3c2 100644 --- a/README.md +++ b/README.md @@ -18,7 +18,7 @@ On the same hardware KeyDB can perform twice as many queries per second as Redis Why fork Redis? --------------- -KeyDB has a different philosophy on how the codebase should evolve. We feel that ease of use, high performance, and a "batteries included" approach is the best way to create a good user experience. While we have great respect for the Redis maintainers it is our opinion that the Redis approach focusses too much on simplicity of the code base at the expense of complexity for the user. This results in the need for external components and workarounds to solve common problems - resulting in more complexity overall. +KeyDB has a different philosophy on how the codebase should evolve. We feel that ease of use, high performance, and a "batteries included" approach is the best way to create a good user experience. While we have great respect for the Redis maintainers it is our opinion that the Redis approach focuses too much on simplicity of the code base at the expense of complexity for the user. This results in the need for external components and workarounds to solve common problems - resulting in more complexity overall. Because of this difference of opinion features which are right for KeyDB may not be appropriate for Redis. A fork allows us to explore this new development path and implement features which may never be a part of Redis. KeyDB keeps in sync with upstream Redis changes, and where applicable we upstream bug fixes and changes. It is our hope that the two projects can continue to grow and learn from each other. diff --git a/src/expire.cpp b/src/expire.cpp index 3bd631459..7af20b850 100644 --- a/src/expire.cpp +++ b/src/expire.cpp @@ -155,9 +155,8 @@ void expireMemberCore(client *c, robj *key, robj *subkey, long long basetime, lo when += basetime; /* No key, return zero. */ - robj *val = c->db->find(key); + robj *val = lookupKeyWriteOrReply(c, key, shared.czero); if (val == nullptr) { - addReply(c,shared.czero); return; } @@ -165,7 +164,7 @@ void expireMemberCore(client *c, robj *key, robj *subkey, long long basetime, lo { case OBJ_SET: if (!setTypeIsMember(val, szFromObj(subkey))) { - addReplyError(c, "subkey does not exist"); + addReply(c,shared.czero); return; } break; @@ -177,7 +176,7 @@ void expireMemberCore(client *c, robj *key, robj *subkey, long long basetime, lo setExpire(c, c->db, key, subkey, when); - addReply(c, shared.ok); + addReply(c, shared.cone); } void expireMemberCommand(client *c) diff --git a/src/server.h b/src/server.h index c4781d1e8..854665c6d 100644 --- a/src/server.h +++ b/src/server.h @@ -813,12 +813,20 @@ public: // First check if the subkey already has an expiration for (auto &entry : m_vecexpireEntries) { - if (entry.spsubkey == nullptr) - continue; - if (sdscmp((sds)entry.spsubkey.get(), (sds)szSubkey) == 0) { - m_vecexpireEntries.erase(m_vecexpireEntries.begin() + (&entry - m_vecexpireEntries.data())); - break; + if (szSubkey != nullptr) + { + // if this is a subkey expiry then its not a match if the expireEntry is either for the + // primary key or a different subkey + if (entry.spsubkey == nullptr || sdscmp((sds)entry.spsubkey.get(), (sds)szSubkey) != 0) + continue; } + else + { + if (entry.spsubkey != nullptr) + continue; + } + m_vecexpireEntries.erase(m_vecexpireEntries.begin() + (&entry - m_vecexpireEntries.data())); + break; } auto itrInsert = std::lower_bound(m_vecexpireEntries.begin(), m_vecexpireEntries.end(), when); const char *subkey = (szSubkey) ? sdsdup(szSubkey) : nullptr;