ashish-goyal / redis

Automatically exported from code.google.com/p/redis
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

Attach "archive bit" to datum #601

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
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 commented 8 years ago
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 commented 8 years ago
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 commented 8 years ago
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