justinpark commented on issue #26395: URL: https://github.com/apache/superset/issues/26395#issuecomment-1907070333
Thanks for all feedback. Here is my answer for all opinions. > john-bodley: ... the left-hand panel will likely define (for searching purposes) an exhaustive list of all database and namespaces (schemas) which i) our current API doesn't handle, and ii) could be rather costly to fetch if the corpus of databases, schemas, and table is large. > Would you mind expanding how these perceived interactions (including the table schema) will likely materialize? > michael-s-molina: ... the search is applicable only to loaded databases. When a user loads a database by expanding its node, we could display a connected icon which would indicate that the database is available for searching. Considering @john-bodley's concerns, the recommendation put forth by @michael-s-molina might be a suitable interim solution until the Superset API is fully equipped for a full-text search of the entire database list. As suggested in Figure 1, we could use varying colors to denote the assets that are available for search. This way, users can easily distinguish which parts are excluded from the search list. |Figure 1| |--| || > betodealmeida: 2. What happens when databases have thousands of tables? Are we going to paginate the sidebar? Similar to the current setup, the entire list will be displayed (as the paginated API isn't supported yet). However, it will be virtually rendered (as-is) within the viewport for better efficiency. > betodealmeida: 3. Currently we have some affordances to show extra table metadata (in Presto, Hive, Trino, BigQuery, and GSheets). How are these going to be displayed in the new design? Indeed, much like the existing UI, the display will be situated beneath the table hierarchy as shown in Figure 2. |Figure 2| |--| || > betodealmeida: 4. We've been discussing https://github.com/apache/superset/issues/22862 (projects, in BigQuery terms) to Superset. It would be nice to keep that in mind during this redesign, to make that work easier. I've contemplated introducing a new hierarchy to support the catalogue. Kindly refer to the newly added "catalogue" section in Figure 2. > geido: I believe the current setup uses the schema dropdown to determine the content of the tables dropdown. Placing the schema dropdown directly above the SQL Editor might imply a strict binding between the SQL Editor and the selected schema. However, it's important to note that the SQL Editor allows for cross-schema queries, so the association between the dropdown and the editor isn't necessarily exclusive. You're right that our current setup uses the schema dropdown to influence the content of the tables dropdown. However, within the tree hierarchy structure, the schema dropdown might be seen as redundant since it's already incorporated into the tree structure. Yet, removing the schema selector could potentially be a step back, given how it's implicitly used when a table name is provided without a specified schema name. (+ We're planning to make the schema dropdown optional, allowing users to run queries even without making a schema selection.) cc: @betodealmeida @geido -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
