ktmud commented on a change in pull request #11970:
URL:
https://github.com/apache/incubator-superset/pull/11970#discussion_r543776285
##########
File path: superset/connectors/sqla/models.py
##########
@@ -1467,6 +1473,29 @@ class and any keys added via `ExtraCache`.
extra_cache_keys += sqla_query.extra_cache_keys
return extra_cache_keys
+ def health_check(self, commit: bool = False, force: bool = False) -> None:
+ check = config["DATASET_HEALTH_CHECK"]
+ if check is None:
+ return
+
+ extra = self.extra_dict
+ # force re-run health check, or health check is updated
+ if force or extra.get("health_check", {}).get("version") !=
check.version:
+ with event_logger.log_context(action="dataset_health_check"):
+ message = check(self)
+ if message:
+ extra["health_check"] = {
+ "version": check.version,
+ "message": message,
+ }
Review comment:
Yes, agreed. We don't need to go that route if it's too much work. Just
laying out my thoughts here in case we want to double down on this feature.
Even if the message depends on specific rule implementation, we can enforce a
basic structure so that it's possible the override the message renders.
> Error and Warning should be treated differently.
This I must humbly disagree. Both are actually a subclass of `Alert` in most
UI libraries, and we see in a lot of places the concept of "error levels"
(error, warning, info). Most of the time, you'd see warnings and errors being
rendered by the same component, just different colors or icons. And in case we
want to render them differently, the shared infrastructure of custom renderer
registry comes handy.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
