Spreadsheet Export for Projects should stringify complex objects

[innerjoin]

For example for releases, the external Id are separated by comma only, having someting like

key: value, key: value, ...

could be easier to parse when:

{"key:" "value", "key": "value", ...}

[alexbrdn]

@mcjaeger , do you think we should save every iterable thing as JSON?

[innerjoin]

That would be my suggestion, With this solution, I could simply use a JSON parser and then I would be able to access every property of a complex object. I'm open for other ideas as well...

[alexbrdn]

Yeah, I get that. I see your point. I only have this little nagging doubt that people who work with the spreadsheet manually, as opposed to programmatically, wouild want to see all lists abc, def turn into ["abc", "def"]

[innerjoin]

Didn't realize that you were mentioning Michael :-)

I can live with the more human readable format we have today, but I would suggest to quote the keys and values, if the datamodel allows to put commas or colons. This would ensure that automated parsers do not trap into situations where the key or value contains colons or commas...

[alexbrdn]

I think that makes sense. Even human parsers might stumble on unexpected commas or colons in values

[alexbrdn]

@innerjoin, what do you think of the idea that we encode list values as CSV (e.g.: "text", "more \"text\"", "text with ',' (a comma) and and '\\' (a backslash)") and apply the same encoding to maps ("key":"weird\"\\,value","key2":"val2")?

I understand your problem, but I don't like the idea of putting JSON into an Spreadsheet. We should somehow keep it readable for non-engineers. I think we should go with CSV encoding or provide an extra functionality to export the same data as in spreadsheet, but in form of a proper JSON document.

What's your take on this?

[innerjoin]

@alex-evo, I like the idea to encode lists as CSV as it's a well known standard even to non engineers.

The data export in form of a proper JSON document can be achieved through the REST API as well.

[alexbrdn]

After some deliberation and prototyping, we decided to go with JSON as you inially suggested, @innerjoin