The problem/use-case that the feature addresses

Our scripts may change due to requirements of our system but current scripting API doesn't provide command for script replacement or script removal. Pushing updated scripts increase memory usage by time-unnecessarily- and only way to avoid this is removing ALL scripts with SCRIPT FLUSH. But it also creates exceptions and "data or service quality" loss when other sub-systems trying to execute another scripts. Providing only SCRIPT REMOVE shasum command will solve the problem.

Description of the feature

A command that allows removal of single script

Alternatives you've considered

1 ) Allow script remove (BEST / CHEAPEST)

Just remove given script, so loading updated script wont increase memory usage.

    SCRIPT REMOVE oldScriptShasum
    SCRIPT LOAD newScriptContent

or

    DEL f_oldScriptShasum
    SCRIPT LOAD newScriptContent
2 ) Allow naming of script and provide update interface

It has better and less confusing interface but may need extra development time

    SCRIPT ADD scriptName scriptContent
    SCRIPT REPLACE scriptName scriptContent
    SCRIPT REMOVE scriptName
    EVALSCRIPT scriptName
3 ) Provide only script replace

Worst alternative because new content has different sum

    SCRIPT REPLACE shasum scriptContent

Additional Information

No additional information

Comment From: yossigo

@alpeer Thank you for this idea.

While this makes a lot of sense when you think of scripts as a kind of "stored procedures", the Redis concept of Lua scripts is different. The use of EVALSHA is considered a kind of optimization, but clients should not generally assume Redis manages a script repository for them. Adding a more specific delete mechanism kind of goes against that.

Having said that, can you provide more details on your use case? How many scripts are used and why is it really the case for so many scripts, how much memory do they consume, etc.? I'm curious to learn more about how the current model fails to solve the problem.

Comment From: oranagra

BTW, this is in some way related to #7814