Merge branch 'unstable' into advanced_db

Former-commit-id: 88152a8f4f9b4e3a82d5f1416930d39bfa91eb47
This commit is contained in:
John Sully 2019-10-16 13:23:19 -04:00
commit b02148db42
4 changed files with 18 additions and 11 deletions

View File

@ -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

View File

@ -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.

View File

@ -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)

View File

@ -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;