The problem/use-case that the feature addresses
While I use a module to do something with a fake slave, it's not so easy for the module to control how to expire the key.
Description of the feature
Actually, it will better if there is a way for module to prevent default key expire action, not just be notified.
A easy idea is to add a checking function in propagateExpire.
//in old propagateExpire
robj *argv[2];
argv[0] = lazy ? shared.unlink : shared.del;
argv[1] = key;
incrRefCount(argv[0]);
incrRefCount(argv[1]);
...
...
propagate(db->id,argv,2,PROPAGATE_AOF|PROPAGATE_REPL);
=>
//in new propagateExpire
robj *argv;
int argc;
if (propateExpireModules(&argv, &argc)) {
//the argv and argc is changed before
} else {
argv[0] = lazy ? shared.unlink : shared.del;
argv[1] = key;
incrRefCount(argv[0]);
incrRefCount(argv[1]);
}
...
...
propagate(db->id,argv,argc,PROPAGATE_AOF|PROPAGATE_REPL);
Alternatives you've considered
Theare are two ways for me to achieve similar target. 1. Create new key space with new access commands just like Redis. These commands are controled by modules. 2. Subscribe the expire event, send an extra command which will prepare a special client state in fake slave before the del/unlink command and then the fake slave will take care of the del/unlink command.
Obviously, these two ways are not so graceful as I wish.
Additional information
It makes sense for modules to control the expire action, not just to get notification from it. It may be a missing ability between modules and Redis key space. Just like: 1. AOF/RDB persistence API 2. DEBUG digest API 3. .etc
Comment From: itamarhaber
Thanks @1000happiness - definitely makes sense to have that.