Why you should migrate from RediSQL to zeeSQL
Last updated
Last updated
zeeSQL is the successor of RediSQL. zeeSQL is RediSQL V2.
It is based on largely the same codebase but improved in several ways with novel features.
Secondaries indexes allow searching Redis keys by value. If you are interested in searching Redis keys by value or manipulate Redis hashes without maintains secondary data structures, secondary indexes are a perfect way to do it.
Secondary indexes have been introduced in RediSQL V2, also know as zeeSQL.
Secondary indexes themselves are a more than valid motivation to switch to zeeSQL instead of keeping using RediSQL.
The APIs of zeeSQL are just better.
They are more flexible, they allow extensions, and they provide more information to the user.
The zeeSQL APIs were improved keeping what worked well with RediSQL and fixing what could have been improved.
The new APIs of zeeSQL, by default, return both the column name and the column type.
This allows writing wrappers or client library that automatically creates the correct type reading from Redis.
In the example below, you can see what RediSQL returned, versus what zeeSQL returns.
The result from zeeSQL is more structured. It contains the columns' name, then their type, and finally the rows.
The result from RediSQL returns directly the rows without providing information about the column name and their type.
Values from zeeSQL and RediSQL can either be:
OK
DONE
Some result set
RediSQL returns either:
A simple string with the value "OK"
An array with first string the "DONE" string
A nested array, that has as first elements of the first subarray, the string "RESULT"
This is clearly suboptimal and it was fixed in zeeSQL.
zeeSQL returns always a nested array.
The first element, of the first subarray, identify the type of the result. It can be either the string "OK", or the string "DONE" or the string "RESULT".
But zeeSQL returns always a nested array.
Let's compare the same workflow with RediSQL and with zeeSQL.
In this example, RediSQL returned three different types of results.
In this other example, zeeSQL returned always a single type of result, a nested array.
Instead of returning a nested subarray, that in some programming language are difficult to manage, we can return a single JSON string that represents the same result set.
This makes working with zeeSQL much simpler in both dynamic and statically typed languages.
The string returned in a valid JSON string.
In RediSQL there is no way to pass arguments to simple queries.
You can either submit a full query, or create a statement, and submit the statement with arguments.
In RediSQL you had no choice, but to create a statement, and bind the arguments. In zeeSQL you can bind them to a simple query, without the need of creating a statement.
zeeSQL is maintained, RediSQL is not maintained anymore.
Code updates, security fixes, and SQLite engine upgrades will happen only in zeeSQL.
No changes at all are expected to RediSQL.
Besides all these upgrades, zeeSQL maintains backward compatibility with RediSQL.
All the RediSQL commands are prefixed by the REDISQL.
string.
In zeeSQL you can find exactly the same commands, with exactly the same semantic, but a different prefix: REDISQL.V1.
.
So if in RediSQL you used the REDISQL.EXEC
command, with zeeSQL you can use the exact same command with REDISQL.V1.EXEC
.
The is a new feature of zeeSQL, not available in RediSQL.
Especially if the arguments are coming from the users you should always submit them as arguments.