The problem with the previous solution was that the `npm ci` command
nuke the `node_modules` folder, including the `.cache` that was used by
default. By moving the cache out of `node_modules` we get to both run
`npm ci` and accelerate `TerserPlugin`
* Relayout SQL Editor
- Refactor SQL editor to remove usage of bootstrap col, row and collapse to simplify the layout
- Replace the react-split-pane libraray with react-split to allow custom styling of the gutter area without sacrifice correctness of the ace editor height calculation
- Rewrite the left pane animation via plain css transition and animate it to slide in and out
- General code and css clean up
* Smooth out the visual transition during dragging
(cherry picked from commit 19f82b729c7a939f12b1c5da6022c0fd76fa3ec9)
* Adjust how the height of the south pane is computed, fixing cypress tests
* Update webpack config to facilitate debugging charts via symlink and update babel plugin version
* update @superset-ui-legacy version
* update packages
* Speed up CI by caching TersetPlugin cache
This should accelerate the `npm run build` part of the build by ~5
minutes or so I believe.
* targeting terser-webpack-plugin/
* Make the target path of the superset logo configuable
There is a need to have the target path of the logo go to different places in different installations of superset. The PR makes the target path (after `/superset`) configurable via the LOGO_TARGET_PATH configuration key and sets the default to the existing `/profile/{{ current_user.username }}/`
* addressing pr comments
This PR introduces the backend changes for a tagging system for Superset, allowing dashboards, charts and queries to be tagged. It also allows searching for a given tag, and will be the basis for a new landing page (see #5327).
# Implicit tags
Dashboard, chart and (saved) queries have implicit tags related to their owners, types and favorites. For example, all objects owned by the admin have the tag `owner:1`. All charts have the tag `type:chart`. Objects favorited by the admin have the tag `favorited_by:1`.
These tags are automatically added by a migration script, and kept in sync through SQLAlchemy event listeners. They are currently not surfaced to the user, but can be searched for. For example, it's possible to search for `owner:1` in the welcome page to see all objects owned by the admin, or even search for `owner:{{ current_user_id() }}`.
Summary: Added limited support for visualizations with Pinot via
Sqlalchemy.
Pinot QL (PQL) is a bit weird and limited, and this patch hacks superset to
deal with that weirdness:
1. Pinot's grouping by time is best done as a long epoch. Grouping by a
time string is really slow and times out.
2. Pinot's response does not respect column aliases. So columns are not
named what they are expected to. So we remember the given column aliases
and then stamp them back onto the dataframe
3. Pinot's Json rest call does not return the output types. Instead
everything is cast to string. So when grouping by time, the group key
is integral and has to be treated specially when casting back to the
dataframe __timestamp column.
4. Finally, pinot does support grouping by on expressions. But those
expressions cannot then appear on the select clause. They are returned
regardless in the response. ie, 'select foo, count(*) from bar group by
foo' is okay, but 'select expr(foo), count(*) from bar group by
expr(foo)' ain't. One must use 'select count(*) from bar group by
expr(foo)'.
I also fixed a couple of things that looked like bugs to me: for
example, the row-ordering-limit should come at the end always.
Test Plan: Tested with the modified pinotdb sqlalchemy driver and an
internal pinot cluster. The pinotdb driver changes are in
https://github.com/agrawaldevesh/pinot-dbapi.
Pinot does not support orderby-limit for aggregated queries. To annotate
a query as an aggregate query, this patch adds a hint to the prepared
select statement that the pinotdb sqlalchemy driver then heeds.
Summary: We want to allow grouping by on expressions, including the
ability to select expressions (without group-by). The UI ain't good yet
.. it is not at the feature parity of say adhoc filters/metrics that
come with a nice text-box to edit the SQL. But
this suffices for my usecase for now.
(The UI would have to be redone ... but that would require some refactoring
to merge the AdhocFilter/Metric/Popover stuff such that it can be used
for this use case too.)
Also fixed a bug in the SelectControl freeForm selection.
Allow selecting all columns easily: Added a new Select-All special item
that users can select to make all the options in the selectable show
up.
The ability to group by arbitrary expressions is useful because now two
users don't need to create custom computed-fields for this.
Introduce a config DEFAULT_RELATIVE_END_TIME which is used when
computing the "Last X days". The default behavior (as currently) is to
let that be 'today', which actually means the 0th second of today. We
can also let it be 'now' which means the data as of now (ie at query
time).
Secondly, also introduce another config IS_EPOCH_S_TRULY_UTC, which
means that the logged time in epoch_s format is actually in UTC.
Currently (as the default) is that it it is in the local (superset
webserver) timezone.
** There is no backward incompatibility with thes config features since
the default behavior hasn't changed. **
Currently, we attempt to hide the nvd3 tooltips (if any were on screen) before we draw a new viz after rerunning a query. The hiding is done by selecting the first nvtooltip element and setting the opacity to 0.
This somtimes leave behind a trail of old tooltips if a tooltip is left behind by this nvd3 bug https://github.com/novus/nvd3/issues/1262. This PR modifies the behavior of how we clean up tooltips between rerun of queries by selecting all nvd3 tooltips and removing them all from the DOM before redrawing nvd3 vizzes.
* Revert "creating new circular-json safe stringify and replacing one call (#6772)"
This reverts commit 11a7ad00b7.
* Revert "Improve Unicode support for MSSQL (#6690)"
This reverts commit c44ae612df.
* Revert "Fix uniqueness constraints on tables table (#6718)"
This reverts commit c4fb7a0a87.
- Rename the default feature flags key in `config.py` to DEFAULT_FEATURE_FLAGS
- Merge default feature flags with user defined ones allowing the latter to overwrite the former
- Expose feature_flags for both server and client to use
- Add a utility method for checking whether a feature flag is on on server side
Summary: Superset code enforces (in Table crud view pre_add) that the
table is unique within <database, schema, table_name). Indeed in commit
15b67b2c6c (in 2016), the model was
updated to reflect that. However, it was never ported over to a
migration.
I am fixing that in this diff. I am choosing to make this be a new
migration instead of fixing an existing one since I want to fix existing
installations also cleanly.
I also considered removing the uniqueness constraint, but that won't
work: First because anyway there are other places where the <database,
schema, table> uniqueness is enforced in code. But also, the .sql field
isn't a first citizen yet: The schema of the table is picked up from the
table-name and the sql part is only used when creating the explore
query. So indeed we want this uniqueness constraint. (Also it breaks the
unit tests in dict_import_export_tests.py)
[Perhaps it can be removed when we have true .sql support, but for now
the user would have to create a database view and he can use that as the
'table name'. That way he gets schema inference also]
Also added INFO logging to the alembic migration.
