BEFORE REDIS 1.0.0-rc1
-- TTL command that returns -1 if a key is not volatile otherwise the time to live of a volatile key.
-- Remove max number of args limit
-- What happens if the saving child gets killed or segfaults instead of ending normally? Handle this.
-- Make sinterstore / unionstore / sdiffstore returning the cardinality of the resulting set.
-- maxclients directive
-- check 'server.dirty' everywere
-- replication automated tests
-- Shutdown must kill other background savings before to start saving. Otherwise the DB can get replaced by the child that rename(2) after the parent for some reason.
-- Document replication
-- Objects sharing configuration, add the directive "objectsharingpool <size>"
-- Make sure to convert all the fstat() calls to 64bit versions.
-- SINTERCOUNT, SUNIONCOUNT, SDIFFCOUNT
+ * Add number of keys for every DB in INFO
+ * Resize the expires and Sets hash tables if needed as well? For Sets the right moment to check for this is probably in SREM
+ * check 'server.dirty' everywere. Make it proprotional to the number of objects modified.
+ * Cover most of the source code with test-redis.tcl
+ * Remove tmp-.... files when saving child exits in the wrong way, to do so use tmp-pid.rdb as filename so that the parent can rebuild the file name just from the child pid.
AFTER 1.0 stable release
-- Use partial qsort for SORT + LIMIT
-- Locking primitives
+ * Consistent hashing implemented in all the client libraries having an user base
+ * SORT: Don't copy the list into a vector when BY argument is constant.
+ * SORT ... STORE keyname. Instead to return the SORTed data set it into key.
+ * Profiling and optimization in order to limit the CPU usage at minimum
+ * Write the hash table size of every db in the dump, so that Redis can resize the hash table just one time when loading a big DB.
+ * Elapsed time in logs for SAVE when saving is going to take more than 2 seconds
+ * LOCK / TRYLOCK / UNLOCK as described many times in the google group
+ * Replication automated tests
+ * some kind of sorted type, example:
+ ZADD mykey foo 100
+ ZADD mykey bar 50
+ ZRANGE mykey 0 1 => bar foo
+ This is able to take elements sorted because a binary tree is used to store
+ the elements by 'score', with the actual value being the key. On the other
+ side the type also takes an hash table with key->score mapping, so that when
+ there is an update we lookup the current score and can traverse the tree.
+ * BITMAP type
+ * LRANGE 4 0 should return the same elements as LRANGE 0 4 but in reverse order (only if we get enough motivated requests about it)
+ * zmalloc() should avoid to add a private header for archs where there is some other kind of libc-specific way to get the size of a malloced block.
FUTURE HINTS
projects / redis.git / blobdiff