Open tdhsmith opened 3 years ago
Creating a transposed CSV would not really be a problem. I would assume that this would be around 10 additional lines of code. Automatically recognizing this and reading it in would then be more of a challenge.
Although I understand the use-case, as you described this in #119, I am still skeptical whether this would be an improvement and is worth the effort, at least from my perspective.
You're comment about the general recommendation regarding the data structure and how to organize this into rows and columns is correct (and I do have a certain amount of experience with big databases). However, here I still decided against it for reasons:
The probability that someone is going to keep hundreds of datasets in a single CSV is from my perspective rather small. On the contrary, I would expect that having a CSV with more than 9 columns (id + 7 players + gm) is rather a very seldom exception. This means that in most cases all columns will fit on the users screen at the same time. But the number of values that the user can provide is rather large. With the current setup the user will only have to scroll down. If the CSV was transposed, then the user would have to scroll sideways, which is far from optimal wrt. user experience.
So this would mainly leave the use-case as described in #119. Hm... Ok, the hardest part of having something like this would probably be to automatically recognize whether a regular or a transposed CSV file was provided. Or we just skip that and have a low-effort version that basically adds another optional flag to the batch create
call, something like --expect-the-csv-to-be-transposed --and-i-suck-at-command-line-flag-naming
. This would result in an additional processing step after reading in the CSV file that transposes it again internally. Possible problems that might need to be handled are comment lines and empty lines.
One more question: Assuming there was support for transposed CSV file handling for the use-case described in #119: What about the other value parameters that are accepted by pfscf? Their number has currently grown, although that will most likely go back a little bit when the new chronicle layout for season 02 is out. But how do you currently then plan to manage this? Are you planning to keep a full list of supported parameters also in the online sheet? Or somehow later add them to the exported CSV?
I have done a quick hack to have transposed CSV output, available at https://github.com/Blesmol/pfscf/tree/transpose if you want to have a look. One exemplary output file is available here: transposed.xlsx (saved as excel worksheet as github does not like to attach CSV files). The regular parameter fields go up to the column with index "CR".
While most spreadsheet/table editors are orientation-neutral, many of them strongly guide the user to orient the data with records in rows and data fields in columns. Since this is contrary to what the tool uses, it'd be nice if
batch fill
could accept such "transposed" data, and perhaps allowbatch create
to emit it as well.