+
You can load modules in 3 ways:
+
+
1. At startup with the `--loadmodule` flag.
+
+ Upon startup you can provide the flag {module_path}. This is the path to
+ the module's file. You can pass this flag multiple times to load
+ multiple modules on startup.
+
+
+
2. At runtime with the `MODULE LOAD` command.
+
+ You can load modules dynamically at runtime using the `MODULE LOAD`
+ command as follows:
+
+
{`MODULE LOAD ${module_path}`}
+
+ This command only takes one path so if you have multiple modules to
+ load, You will have to load them one at a time.
+
+
+
3. At runtime the `LoadModule` method.
+
+ You can load a module .so file dynamically at runtime using the{" "}
+
+ `LoadModule`
+ {" "}
+ method in the embedded API.
+
+
{`err = server.LoadModule("${module_path}")`}
+
+
Loading Module with Args
+
+ You might have notices the `args ...string` variadic parameter when
+ creating a module. This a list of args that are passed to the module's
+ key extraction and handler functions.
+
+
+ The values passed here are established once when loading the module, and
+ the same values will be passed to the respective functions everytime the
+ command is executed.
+
+
+ If you don't provide any args, an empty slice will be passed in the args
+ parameter. Otehrwise, a slice containing your defined args will be used.
+
+
To load a module with args using the embedded API:
+
+ {`err = server.LoadModule("${module_path}", "list", "of", "args")`}
+
+
To load a module with args using the `MODULE LOAD` command:
+
+ {`MODULE LOAD ${module_path} arg1 arg2 arg3`}
+
+
+ NOTE: You cannot pass args when loading modules at startup with the
+ `--loadmodule` flag.
+
+
+
List Modules
+
+ You can list the current modules loaded in the SugarDB instance using
+ both the Client-Server and embedded APIs.
+
+
+ To check the loaded modules using the embedded API, use the{" "}
+
+ `ListModules`
+ {" "}
+ method:
+
+
{`modules := server.ListModules()`}
+
+ This method returns a string slice containing all the loaded modules in
+ the SugarDB instance.
+
+
+ You can also list the loaded modules over the TCP API using the `MODULE
+ LIST` command.
+
+
Here's an example response of the loaded modules:
+
{`1) "acl"
+2) "admin"
+3) "connection"
+4) "generic"
+5) "hash"
+6) "list"
+7) "pubsub"
+8) "set"
+9) "sortedset"
+10) "string"
+11) "${module_path}"`}
+
+ Notice that the modules loaded from .so files have their respective file
+ names as the module name.
+
+
+
Execute Module Command
+
+ Here's an example of executing the `Module.Set` command with the
+ embedded API:
+
+
+ Here's an example of executing the COPYDEFAULT custom command that we
+ created previously:
+
+
{`// Execute the custom COPYDEFAULT command
+res, err := server.ExecuteCommand("Module.Set", "key1", "10")
+if err != nil {
+ fmt.Println(err)
+} else {
+ fmt.Println(string(res))
+}`}
+
+ Here's how we would exectute the same command over the TCP client-server
+ interface:
+
+
{`Module.Set key1 10`}
+
+
Unload Module
+
+ You can unload modules from the SugarDB instance using both the embedded
+ and TCP APIs.
+
+
Here's an example of unloading a module using the embedded API:
+
{`// Unload custom module
+server.UnloadModule("${module_path}")
+// Unload built-in module
+server.UnloadModule("sortedset")`}
+
Here's an example of unloading a module using the TCP interface:
+
{`MODULE UNLOAD ${module_path}`}
+
+ When unloading a module, the name should be equal to what's returned
+ from the `ListModules` method or the `ModuleList` command.
+
+