-
Notifications
You must be signed in to change notification settings - Fork 323
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ensure Table Visualisation is the Default Visualization for Tables #4120
Ensure Table Visualisation is the Default Visualization for Tables #4120
Conversation
0573b07
to
8682a25
Compare
…ation_For_Table_184267396
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, having tables on by default will make life of everyone way easier.
@@ -11,7 +11,7 @@ loadStyleFromString(scrollbarStyle) | |||
// =========================== | |||
|
|||
class TableVisualization extends Visualization { | |||
static inputType = 'Any' | |||
static inputType = 'Standard.Table.Data.Table.Table' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unit tests have been written where possible.
Is there a test to fail if the Table
type is renamed? Types get renamed quite frequently in the stdlib and I'd be sad to see this functionality stop working without a warning/failing test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unit tests have been written where possible.
Is there a test to fail if the
Table
type is renamed? Types get renamed quite frequently in the stdlib and I'd be sad to see this functionality stop working without a warning/failing test.
That is a good point. But I am somewhat unsure how to do this, as we don't currently have working integration tests.
Do you think it would be sensible to put in a test in the standard library that checks the name of the type of Table
and says something like "If you need to change this test, also update visualization/java_script/table.js:14
? "
let result = next_on_list.or_else(|| vis_list.first()).cloned(); | ||
result |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Return directly. Linter should complain about it.
// Visualisations are order by "matching the type" first, followed by and then "matching any | ||
// type". So we just take the first one, which should be the most appropriate one. | ||
// This should be replaced with the proper solution described in | ||
// https://www.pivotaltracker.com/story/show/184390437 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add TODO mark in this comment.
…ation_For_Table_184267396
static inputType = 'Any' | ||
static inputType = 'Standard.Table.Data.Table.Table' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried building the IDE to verify this, but after wasting a lot of time I'm still having some troubles using the new build script on Windows (I will try figure this out in due course).
In the meantime, I have a hunch (the one I wanted to verify before posting, but got impatient): if we specify the inputType of visualization to be Standard.Table.Data.Table.Table
, will the Table visualization even show at all for Database Tables whose type is Standard.Database.Data.Table.Table
? I think it is important to not break the Table visualization on the Database module and would consider breaking it as a regression.
I'm not sure if this PR causes it (as I was unable to verify empirically), but looking at the code I'm afraid it may.
btw. cc @jdunkerley I think this is another argument for why we should migrate towards a single facade Table type that will only then delegate to the proper backend (be it DB backend or in-memory) under the hood. Having one Table type instead of 2 (or more) will be much better. Will probably be worth doing as part of the SQL IR improvements.
For now though, it would be good to ensure if we can keep the Table visualization on Database Tables too. Can we use sum types in inputType
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While this is only a temporary solution until such time as we have the method calling default_visualization
, @radeusgd is correct we need this on a few more types. Could we make the inputType an array of types instead of a single value?
For now, Table viz should be the default for Vector, Array, In Memory Column and In Memory Table.
And SQL should be the default for Database Column and Database Table.
We are very likely to increase this list over the next few days (I want to name Map and JS Object for example default to the Table) so this mechanism is critical assuming that #5195 will not be completed for a while.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@radeusgd - I don't think the facade type has anything to do here.
And at least so far attempts to use such a type within Enso have been annoying. I tried this for the database connection type with a facade calling onto a backing true connection but the approach was very unpleasant and didn't work well. Either way, a discussion for a different space.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There can be any number of types, but there is one limitation: the matching is done on the name as a string. The only special handling is done for Any
. So I can add that back in to ensure this stays usable for all types. And I can add more types for which it makes sense for this to be the default.
So the list of types to add is
Standard.Database.Data.Table.Table
Vector
Array
In Memory Column
In Memory Table
Any other ones that come to mind? @jdunkerley @radeusgd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes please. For the first pass:
Table:
Standard.Base.Data.Vector.Vector
Standard.Base.Data.Array.Array
Standard.Table.Data.Table.Table
Standard.Table.Data.Column.Column
and lets make SQL viz the default for:
Standard.Database.Data.Table.Table
Standard.Database.Data.Column.Column
We can then hopefully easily add to this as we need later on. (ideally without bugging your team!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd just like to ensure that while for
Standard.Database.Data.Table.Table
Standard.Database.Data.Column.Column
we have the SQL visualization as the default, theTable
visualization should still be available to choose for these types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes the Table viz should definitely be available for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Table:
* `Standard.Base.Data.Vector.Vector` * `Standard.Base.Data.Array.Array` * `Standard.Table.Data.Table.Table` * `Standard.Table.Data.Column.Column`
All added.
and lets make SQL viz the default for:
* `Standard.Database.Data.Table.Table` * `Standard.Database.Data.Column.Column`
Already seem to be defined as the input for SQL vis, so they should have it as default now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MichaelMauderer / @farmaazon is #5195 planned for the release?
I don't think it is. @farmaazon ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd just like to ensure that while for
* `Standard.Database.Data.Table.Table` * `Standard.Database.Data.Column.Column` we have the SQL visualization as the default, the `Table` visualization should still be available to choose for these types.
I've re-added “Any” to Table Vis can be chosen for every node. This might be the best compromise here until we get the proper system.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a great step forward. Thanks for getting this in place.
…ation_For_Table_184267396
…ation_For_Table_184267396
…ation_For_Table_184267396
…ation_For_Table_184267396
…ation_For_Table_184267396
…ation_For_Table_184267396
…ation_For_Table_184267396
…ation_For_Table_184267396
Closes #5639 This PR fixes a regression introduced in #4120, due to which new nodes that were being edited had an empty visualization preview. Now newly created visualization containers do get a default visualization set even before the visualization's input type is set. https://user-images.githubusercontent.com/117099775/221256294-c87a50da-c8b0-4f00-bf84-f5ae551fca72.mp4
Pull Request Description
Adds a mechanism for the GUI to choose an appropriate default visualization for a newly created node.
Peek.2023-02-03.15-26.mp4
Important Notes
This is a workaround for missing functionality that would take much longer to implement.
Checklist
Please include the following checklist in your PR:
Scala,
Java,
and
Rust
style guides.
./run ide build
and./run ide watch
.