You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@BHagedorn-IDM : another problem/challenge. The SeasonalityCurves table should be the other way round.
In other words, this ...
... should really be this:
There are several reasons:
It's standard practice for columns to represent fields and rows to represent data tuples.
It's hard to validate whether the table is correctly laid out if there's no predefined column set. In most of the other tables we know which columns to expect, and we can then assume any other columns were put there for the user's own purposes. But as is there's no way to determine which columns contain real data without checking whether the column heading is cross-referenced from the Seasonality Offsets table. We do referential integrity checks like this at various places, but doing one when the table is first loaded would create load order dependencies. Better for the initial load to limit itself to a basic sanity check of the table format, with more complex referential checks happening later.
It's bad practice for column names to contain data, in this case the index name for the curve. Note how in the alternative format there's an explicit ID field. (Under the covers, one of the first things the code does is to transpose the table so the curve names become available as values on which to do a join to the Tasks table. Changing the sheet format would actually simplify the code.)
Obviously this would be a breaking change, so I'm not going to do anything until we make a considered decision.
In other words, this ...
... should really be this:
There are several reasons:
Obviously this would be a breaking change, so I'm not going to do anything until we make a considered decision.
Originally posted by @celiot-IDM in #219 (comment)
The text was updated successfully, but these errors were encountered: