Export csv

[sealemar]

Idea

Quiet often while working with Redis the user might feel a need to have counters per event. Events could obey some hierarchy, i.e.

user/1/newPosts
user/2/newPosts
...
user/n/newPosts

user/1/to-user/2/messages
user/3/to-user/1/messages

Would be useful if redis-browser could somehow represent the data from all of these keys in some kind of a table view.

Realization

MS Excel, OS X Numbers, Libreoffice alternative - these are all good examples of software which can pivot, sort, filter, slice and dice table data (even hierarchial data).

This commit addresses an Export to CSV format to be consumed by such apps.

Implementation

"Export CSV" is an extra button in the top-right corner of the header. When clicked, opens a form similar to "Configure Redis Connection" form. From there the user is able to choose:

• Include keys - keys to include in the output as per Redis KEYS man.
• Exclude keys pattern - regex which excludes the keys from the output.
• Filename - a file with that name will be downloaded if export was good.

Only Redis String datatype is supported for exported keys for a reason - the keys and values are extracted to be opened in MS Excel, Libreoffice alternative or OS X Numbers.

Keys are broken down in separate CSV fields the same way the keys are broken down into a hierarchy view on the lefthand side of the UI - by delimiter [:/]

Configuration

"Exclude keys pattern" comes from config.yml. A connection now has an optional parameter - exclude_pattern. Example

exclude_pattern: "^.+/total/.+$"

"Include keys" - if no key is selected from the tree on the left hand side - "*", otherwise - the selected key.

[sealemar]

Hello there, is this repo still alive?

[szajbus]

@sealemar Sorry for delay, I'm trying to bring this repo back to life recently.

I like the feature but there are still some problems with the solution.

1. You'll get WRONGTYPE Operation against a key holding the wrong kind of value error when trying to GET the key which is not holding a string as a value.
2. Perhaps SCAN would be more efficient than KEYS and GETs combination.

Especially the first issue is a blocker, without it solved the feature handles only very specific scenarios and is confusing to users.