The rest is as today with EVALSHA command.The return value from the function will be returned to the user as a result. The function will receive all arguments given after NUM_KEYS. Usage: FUNCTION CALL NAME NUM_KEYS key1 key2 … ARGS arg1 arg2Ĭall and execute the function specified by NAME. In this case the engine should return a more precise error and this error will be returned as well. The given function failed to be created by the engine.The function name is already taken and REPLACE was not used.The command will return OK if created successfully or error in the following cases: BLOB - A blob of data representing the function, usually it will be text (e.g., Lua code).DESCRIPTION - optional argument describing the function and what it does.ARGS DESCRIPTOR - an optional argument that can be given for argument validation on run time, see Arguments Descriptor.REPLACE - if given, replace the given function with existing function (if exists).NAME - the name of the function that can be used later to call the function using FUNCTION CALL command.ENGINE - The name of the engine to use to create the script.Information about the engines will include the following: The section will show general information about the engines and functions. Function Commands INFO functionsĪ new proposed INFO functions section will be added to the INFO command. We propose to support multiple engines in the same Redis process, in order to support multiple function programming languages. Function EnginesĪs mentioned above, the engine is the component that is responsible for executing functions. Function code is loaded into the specified engine that compiles and stores it.Īfter the function is created, it can be invoked using FUNCTION CALL command that executes the named function.Ĭreated functions are also propagated to replicas and AOF, and are saved as part of the RDB file. To do this, the FUNCTION CREATE command is used. Function Life CycleĪ function needs to be created and named in Redis before it can be used. This implies that functions are intended for short execution times, and not long running operations, just like Lua scripts today. During function execution, Redis is blocked and doesn't accept any commands. Important: As with the current scripting approach, functions are atomic. Naturally, the first engine that will be implemented is the Lua 5.1 engine, but we propose additional engines to support other languages such as JavaScript. Engines can execute functions in any language as long as they respect certain rules like memory limits and the ability to kill a function's execution (the full list of engine capabilities will be covered in detail). Instead, we define an engine component that is responsible for executing functions. The design makes no assumptions about the programming language in which functions are implemented. Lua is simple and easy to learn, but for many users it’s still an obstacle. This new design also attempts to decouple the language in which functions are written. They provide the same core functionality, but they are guaranteed to be persistent and replicated, so the user does not need to worry about them being missing.Ĭonceptually, if current scripts are treated as client code that runs on the server, then functions are extensions to the server logic that can be implemented by the user. The proposed Redis Functions are an evolution of Redis' scripts. These led to the following definition of Redis Functions. EVAL inadvertently promotes the wrong pattern of rendering scripts on the client side instead of using KEYS and ARGV.Meaningless SHAs are harder to identify and debug, e.g.Using EVALSHA inside MULTI is inherently risky.Clients can either use EVAL only (inefficient), or implement a more complex logic of trying EVALSHA and falling back to EVAL.Scripts cannot be considered a way to extend Redis, like stored procedures.This approach greatly simplifies the server side and is proven to be useful in many cases, but it also has several major drawbacks: By contract, may disappear and need to be re-loaded by the client.Today, Lua scripts are considered an extension of the client they are: We also propose a modular implementation based on engines (languages), to make it easy to support several languages for Redis Functions. These new scripts are called Redis Functions. As such they are persistent, replicated, and named. With the new approach, scripts are a part of the server. The new mechanism extends the existing Lua scripting approach that assumes scripts are part of the application and are only handed to the server for execution. The following is a proposal for a new way mechanism to program Redis.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |