Query

A deepening of the query is required. To request data, the user is supposed to use a query in custom format, consisting of a combination of several strings enclosed in quotation marks (""), whose main component is a script in LUA language:

"LUA_SCRIPT"||"KEY::DATATYPE"||"KEY::DATATYPE"||"KEY::DATATYPE"

The format of this query is very stringent, but it is necessary to limit the great potential of the script. Analyzing the query, we can see how each component of the command is enclosed by quotation marks (""), and separated from the others by a specific combination of characters (||). Even more internally, each "label" is then separated again by a second separator (::). Next, it will be explained carefully what each of the strings represents.

Lua script and redis

This type of script is universal and can be used for any application, but it's useful as it allows interaction with redis databases through particular calls: in fact, through the redis.call() construct it is possible to make specific requests to the server, passing as parameters of the function the commands typically used in the redis CLI.

Both the script and the call to the redis DB can return different combinations of data types (integer, float, hash, lists); in the case of the component analysis, the only accepted combination is that of the hash for the redis.call(), and the List<byte[]> for the LUA script. This combination is valid even if more than one hash record is retrieved from the DB.

The hash data type represents a sort of container, in which the data are enclosed in the form of "key-value": inside each record, then, there may be zero, one or multiple fields, in which each value is associated with a specific key. The values can be of different types (integer, float, string), but this information is lost when the values are extracted with the script in the form of bytes[]. This ambiguity is not allowed in the WireRecord system, so logic is needed to recognize the nature of the input value.

Key-DataType placeholder

The problem of type ambiguity is solved by adding some known constructs within the query: in fact, after the lua script, it must be explicitly indicated what are the expected keys within the hash, and what type of data is expected.

The "KEY::DATATYPE" placeholder serves precisely this purpose: for each of the keys that make up the hash record, the type of data that is expected must be indicated. Allowed types are: INTEGER, LONG, FLOAT, DOUBLE, STRING, BYTE_ARRAY.

The ratio between placeholders and keys in the record must be 1:1, because through the number of placeholders can be traced with precision both the number of fields in the record, in what type of data the user expects to get the associated values, and how many records were required for the script.