Attach "archive bit" to datum

[GoogleCodeExporter]

have you given any thought to attaching an "archive bit" to redis data?

for example, in socketstream uses redis but extra copies of the data for the 
sole purposed to if it has changed, since only changed data is posted to the db

if redis were to keep a settable archive bit it seems to me it could very 
cleanly eliminate a lot of app overhead.  I understand ignorance is bliss, but 
it seems that the overhead on redis would be small - mostly a set of 
independent function calls and one bit extra per datum.  nor do I think scope 
creep - first one bit and then another - would be a problem.

if an interest and seems plausible, would be happy to contribute some of my own 
work, but if it's basically a bad idea, then...

Original issue reported on code.google.com by bangkokm...@gmail.com on 4 Jul 2011 at 12:26

[GoogleCodeExporter]

The answer is probably "no", but what do you mean by "archive bit"? Just 
something that you can set to 1, which is reset to 0 when the data is updated?

You can emulate this yourself by using MULTI/EXEC and writing to a secondary 
"this data was updated" key, which can hold a set, zset, or hash (depending on 
how much data you want to store about the updated key).

Original comment by josiah.c...@gmail.com on 6 Jul 2011 at 12:43

[GoogleCodeExporter]

exactly

yes, could do, but would huge overhead plus require a wrapper around redis
functions to achieve transparent functionality, eg, reset to 0

anyway, I'm a db bigot, and I see this same problem over and over again, and
from my perspective thought would be nice for formalize.  that said, most
programmers nowadays are app oriented, which puts things in a different
point of view.

keep me in mind if you think you might want to move in this direction!
 thanks

Original comment by bangkokm...@gmail.com on 6 Jul 2011 at 6:39

[GoogleCodeExporter]

Josiah is right, this will not be added. A single bit can be enough for you, 
but this doesn't mean it is enough in the general case. Instead, you might want 
to keep a set of users who changed that particular key, or a sorted set where 
you include the timestamps of the changes, or a hash where you count and 
differentiate particular changes, or... Using a wrapper around your client 
code, that pipelines the updates to the archive key together with the original 
update seems the way to go here.

Original comment by pcnoordh...@gmail.com on 6 Jul 2011 at 11:05

• Changed state: WontFix