Fix Version/s: None
Sprint:SUIT Sprint 2018-05, SUIT Sprint 2018-06, SUIT Sprint 2018-07
Team:Science User Interface
Currently we can display the unit for each column in the table display.
It will be very useful to display the data type for each column.
we should use the similar check on/off option for unit display for this option.
- is triggering
DM-14744 Set unit to be displayed by default in table header
- relates to
DM-15176 Improvement on the table option popup
- To Do
- links to
I can't view this in Safari because of the self-signed certificate. I haven't figured out how to work around that - recent versions of Safari don't offer an obvious path to accept the certificate.
Attempting to view it in Firefox caused a fresh copy of Firefox 60.0.2 to crash while loading the results of a query. I have never seen this happen before with Firefly that I can recall. Upon reloading, the crash did not re-occur.
In a table result, the vertical spacing between the column name, the units (in parentheses) and the data type is very cramped. See attachment. I would suggest adding a pixel or two.
Now that we are making these names public, I wonder if "string" would be preferable to "char", which has some complicated implications for people with a C background. (In that context, I would ask: what kind of strings are these? 7-bit ASCII? 8-bit ISO-Latin-1? Unicode?)
It is odd that the data types are not displayed in the "Table Options" dialog along with the units. I think this should be fixed. I am much more likely to want to just occasionally look up the data type in this dialog than I am to want to permanently commit screen real estate to putting it in the header, in fact.
It is also odd, from a user perspective, that there is a completely different "dbtype" in the table schema layout on the query screen, not at all the same as the "data type" we are now displaying. I understand the historical reason for the discrepancy - "dbtype" is a formal SQL database data type, versus "data type" being a Firefly concept.
Now that we use a database internally for tables, what are the actual database data types used internally that correspond to the old "data type" strings?
Pending the answer to that, I don't have a good suggestion for an improvement in this area right now. It is part of a "cognitive style" in which Firefly tends to expose technical implementation details, though, and I'd like to continue thinking about it.
DM-15176 has been created to address the issues raised by reviewer.
Is this available on a Kubernetes build?