Early Access Program News

DataGrip 2022.3 EAP 2: Redis Support

Summary

In DataGrip 2022.3 EAP 2, we’ve implemented a preliminary iteration of long-awaited support for Redis. Here is the list of what is now supported:

  • Connectivity: Redis Single Instance.
  • Introspection: Introspection of databases and keys, including the ability to set a default key filter for the introspector.
  • Database Explorer: Separate folders for keys of different types for Redis v6.0+, and one folder with all keys for older versions.
  • Query Execution: The JDBC driver supports the execution of the majority of queries.
  • Coding assistance: Code highlighting, keyword completion, and resolution for databases and keys.
  • Object Editor: Renaming and deleting keys.
  • Data Viewer: Filtering and JSON highlighting.

Connectivity

You can now create simple Redis data sources. To do this, specify the host, port, and default database. You also need to provide a Default key filter value for the introspector, as you may not want all the keys to be introspected and displayed. The filter should be defined as a regular expression.

Introspection

Databases

DataGrip gets a list of all of the available databases, so you can check which ones need to be introspected. The number of available databases is set on the server side per user. Usually, this number is 16 by default for a Redis Single instance. The default database is set to ‘0’, but you can reassign it in the connection properties.

Keys

The introspection of keys is performed with a SCAN command. By default, DataGrip sets the COUNT option value to 1000, but you can change this value to adjust the balance between the blocking effect and the speed of the introspection.

Important for Redis v5.x and older! SCAN only allows you to download lists of keys of different types separately starting with Redis v6. Requesting a type for each key is an extremely resource-intensive operation, given the possible number of keys. So the key type remains unknown after introspection in Redis versions below 6. This leads to some differences between the support available for Redis v6+ and versions below 6.

Database Explorer

Redis v6+

Database Explorer now displays the keys in your database. Since we know the key types, all of the keys are separated by type.

Redis v5.x and older

Since the key types are unknown, all of the keys are grouped into one folder. The key names are unique regardless of type.

With the new filtering functionality we released in the previous EAP, searching for a key is as easy as pie!

Query execution

General

We’ve implemented our own JDBC driver for Redis. It is based on the open source native Redis Client. Query execution is arranged as follows:

  • Sending a command: The client cannot simply send the command text – it needs it to be split into tokens. This division is implemented inside the JDBC driver.
  • Processing the results: The client returns lists with arrays of bytes, and depending on the command, this result has to be encoded. After that, the client structures are converted into maps so that DataGrip can display them as JSONs. The top level of these maps is expanded into the table’s columns.

All native commands are now properly highlighted, but we are adding more to the built-in Redis grammar. If a command is not highlighted (for example, if it’s a renamed command), you can still run it by selecting the statement’s line and invoking the Execute action.

Code editing

Basics

All native commands are now properly highlighted, but we are adding more to the built-in Redis grammar. If a command is not highlighted (for example, if it’s a renamed command), you can still run it by selecting the statement’s line and invoking the Execute action.

You can also write single comments with `--` symbols.

Code completion and resolution

Code completion for databases and keys now works as expected.

In Redis, keys are created through data modification queries. This means that there should not be unresolved references in these statements. DataGrip doesn’t show unresolved reference warnings for these not-yet-existing objects.

For Redis v6.0 and higher, the type keys relevant to a given context have higher priority.

Object editing

Databases and keys are two major types of objects in Redis. Here’s what you can or cannot do with these objects in DataGrip:

Databases: because the number of the databases is defined in the server settings and the names are numbers, you can’t add, delete, or rename databases.

Keys: they can be deleted and renamed, but it is not possible to create them, since it is impossible to create an empty key. 

Data viewer

Basics

Key data is read-only, so you cannot edit any data via the UI in DataGrip. But many other important features like paging or filtering are supported in the data viewer. Here is the table of what is supported for each key type:

Retrieve dataRow countSupports limit page sizeSupports offset for pagingSupports filterAllows sorting by IDE(== not ordered)Supports sorting by querySupports reversing
String++N/AN/A
List++++++
Set+++++
Sorted Set++++++++
Hash Table+++++
Stream+++++
ImplementedYesYesYesYesYesNoNoNo

Data display

The keys of different types are displayed in different ways:

  • String: A table with one column (value) and one row.
  • List: A table with one column (value) and one or several rows.
  • List: A table with one column (value) and one or several rows.
  • Set:  A table with one column (value) and one or several rows.
  • Sorted Set: A table with two columns (value and score) and one or several rows.
  • Hash Table: A table with two columns (field and value) and one or several rows.
  • Stream: A table similar to a document-like collection.

More details on stream keys

Stream keys are the most complex type of collections in Redis. It was crucial to implement support for them because the most popular plugin for using Redis in IntelliJ-based IDEs lacks it.

One object in the stream key is the collection of an object ID and a map (many fields with values). This structure is very similar to the collection structure in a MongoDB collection, but with one tiny difference: the object ID is stored “outside” of the fields. The vault itself is expanded to several columns on the UI level.

Filtering mechanism

The key data can be filtered and it is implemented via various statements per type. Since there is no explicit WHERE clause in Redis statements, the beginning of the statement is written as a prefix in the Filter field.

Here is the list of key types in the following format: ‘what should be placed in the filter’ → ‘what is returned in the data viewer’.

  • String: Not applicable
  • List:  LINSERT statement – Index → Index value.
  • Set: SMISMEMBER statement – The space-divided list of values → true or false for each value. False is returned for the objects absent in the set.
  • Sorted Set: ZMSCORE statement The space-divided list of values → score or null for each value. Null is returned for the objects absent in the sorted set.
  • Hash Table: HMGET statement – The space-divided list of fields → value or null for each value. Null is returned for the objects absent in the hash table.
  • Stream: XREAD statement – The start and the end of id range → the corresponding stream objects

JSON value detection

Another feature we that we implemented based on your feedback was the most upvoted DataGrip ticket ever:

Redis stores values as strings, and DataGrip automatically detects whether the string values are correct JSONs. If they are, the Value Editor (Shift+Enter) can display formatted and highlighted JSON:

This feature can be turned off in the settings:

That’s it! We hope that you will try this build and experiment with Redis support. You can download the new build from our website or via Toolbox App.

There is still time to fix issues before the official release happens in late November, so be sure to let us know if you encounter any problems. Thank you and stay tuned!

image description

Discover more