CSV / Tabular output

[alexwennerberg]

First off, this is a great tool!

Something I often do with the output from dynein is convert it to a tabular format with https://github.com/alexwennerberg/json2csv

I wonder if making CSV or some other tabular format for displaying attribute values may be useful to add to this tool. It wouldn't work for all data (eg highly nested data) but could be valuable in a number of practical situations. If this is something that could be useful, I'd be happy to put together a PR for it

[StoneDot]

Thank you for filing your request to dynein. I appreciate your feedback.

I infer you are using the command like dy scan -o json | json2csv, please let me know if I misunderstand the situation.
While adding more output formats could be useful, there are some potential challenges to consider. As you mentioned, the CSV format does not fit well with nested data, and it has a lot of dialects while RFC 4180 exists. Due to this reason, I think passing the result of the dy command to another command like json2csv is a better way to format data into CSV.

However, if you feel unhappy with the default output, meaning table format, it changes the story. I want to hear about your concern or needs for the default output. Could you share your background motivation or use-case to convert the output to a CSV file? I'd be happy to discuss this further and hear more about the scenarios where a CSV output would be particularly valuable for you. Feel free to share additional details or examples, and we can continue to explore the best approach together.

[alexwennerberg]

I think you're right that csv isn't exactly what I'm looking for, but rather more sophisticated tabular output. the --table output looks like this:

Key                      Attributes
(key string)         (truncated json)

The attributes in this case are both truncated and in a json format. I think a preferable output would be one in which all the top-level attributes are split out, so that in the (common) case where data is not highly nested, it's much easier to read at a glance. What do you think?

So instead you'd have:

Key               Attribute1           Attribute2       ..etc

[StoneDot]

I'm sorry for the delay in responding and thank you for sharing your thoughts.
I can relate to the point you mentioned. I agree that the suggested tabular output format would be more suitable for many users, and NoSQL Workbench uses the same strategy. That being said, we also need to pay attention to backward compatibility. I think introducing a new format option and adding a configuration to change the default output format is a good way to improve this pain point. How about this suggestion?
I would like to tag this issue as a feature enhancement due to this perspective.