Live data from Hacker News

Redis 4.0 RC1 is out

antirez.com

21–30 of 30 posts

Re: Redis 4.0 RC1 is out

#21
post #14
post #10

Earlier quoted context omitted.

Ok I'll talk ;-) The matter is that currently, if you delete a key, you know that the command returns once the memory is reclaimed. UNLINK is conceptually like DEL, but the memory reclaiming, while fast because there is a thread doing only like that, is asynchronous. So in certain use cases, while semantically identical if you think at what happens to data, the two commands are semantically different in the way memor…

Maybe a new command like "DELSYNC" should be added that acts like the current DEL behavior, and in a future version DEL could be changed to act like UNLINK?

Or call the new version DEL ASYNC or DELASYNC instead of UNLINK?

Re: Redis 4.0 RC1 is out

#22
post #14

Earlier quoted context omitted.

Maybe a new command like "DELSYNC" should be added that acts like the current DEL behavior, and in a future version DEL could be changed to act like UNLINK?

Or call the new version DEL ASYNC or DELASYNC instead of UNLINK?

For what little my opinion matters, I agree it would be clearer if the name helped to indicate that the semantics are the same except it's just an asynchronous DEL. Better than relying on a reference to unix semantics, no?

Re: Redis 4.0 RC1 is out

#24
post #16
post #15

Earlier quoted context omitted.

This doesn't sound so bad. Should just state this limitation clearly in the notes. Otherwise people will assume something a lot worse is going on given how you phrased it.

Yep it was just a joke. I'll update the post.

I understood it as such. Don't let the humor-impared* cramp your style. I'm sure a double-digit percentage of Redis' success is the result of your excellent writing and the character it adds to the project.

*but you could always add a footnote to avoid conspiracy theories about the CIA's efforts to infiltrate your memory reclaiming strategy.

Re: Redis 4.0 RC1 is out

#27
post #14
post #10

Earlier quoted context omitted.

Ok I'll talk ;-) The matter is that currently, if you delete a key, you know that the command returns once the memory is reclaimed. UNLINK is conceptually like DEL, but the memory reclaiming, while fast because there is a thread doing only like that, is asynchronous. So in certain use cases, while semantically identical if you think at what happens to data, the two commands are semantically different in the way memor…

Maybe a new command like "DELSYNC" should be added that acts like the current DEL behavior, and in a future version DEL could be changed to act like UNLINK?

Async in Redis is the exception, so I don't think delsync is necessary. DELASYNC doesn't sound bad though, assuming the functionality is exactly the same, but async.

Re: Redis 4.0 RC1 is out

#28
post #16

Earlier quoted context omitted.

Yep it was just a joke. I'll update the post.

I understood it as such. Don't let the humor-impared* cramp your style. I'm sure a double-digit percentage of Redis' success is the result of your excellent writing and the character it adds to the project. *but you could always add a footnote to avoid conspiracy theories about the CIA's efforts to infiltrate your memory reclaiming strategy.

Haha thanks :-) The footnote looks like an excellent idea. EDIT: done.
Post reply on HN