vbrunelle / pivotableform Goto Github PK

In the README, make sure that users know that they have to melt their data if they want to use the form the way they would like.

For example, instead of having multiple columns of values, one per field, the users should create a column called "Fields" and another column called "Values". The values of their field will go in the "Values" column, and the associated field name is going to be cell of the "Fields" column.

Names of melted columns can absolutely be something else if desired.

That way, pivotableforms can be extremely flexible, at the expanse of usability. Let's think if we want to make dataframe transformations as part of this project's scope, but for now, I can see more advantages by letting this project skip this step and let the user use its favorite tool to melt the data.

Unlike a fact table that we want to make a pivotable from, we could use, in this project, a simple Cartesian format. Example, we have a unique set of natural keys, and a set of values.

Let's take this for example:

Date |    Employee |     Score |  WorkshiftDuration  

Day 1 | Vincent | 10% | 9h
Day 1 | Steph | 99% | 8h
Day 2 | Vincent | 60% | 5h
Day 2 | Steph | 55% | 6h

In this last "table", we can see that the natural key is composed of two fields (Date and Employee). The data is composed of two values: Score and WorkshiftDuration, which are both expressed numerically.

This, however, doesn't seem like it can be read from the pivotableform.

The key with this dataformat is that we have some fields for the natural key, and some fields for the values. We do not even need to aggregate over the keys, as they should be unique.

To make it possible, I believe that the script should do the following things upon receiving the data:

1. Knowing that the data format is tabular, and not a fact table.
2. Determine which are the columns in the key, and what columns are values
3. Run some tests to avoid duplicate values in the keys
4. Keep the aggregators. We cannot assume that the new aggregator is always going to be "first". What if the user removes a field of the key from its table?