mapledan commented on code in PR #42785:
URL: https://github.com/apache/superset/pull/42785#discussion_r3963633679


##########
superset/jinja_context.py:
##########
@@ -797,6 +797,36 @@ def get_context(self) -> dict[str, Any]:
         """
         return self._context.copy()
 
+    def has_template(self, sql: str) -> bool:
+        """Whether the SQL contains anything for ``process_template`` to expand
+
+        Lexed rather than parsed, so that a comment -- which leaves no trace in
+        a parsed template -- still counts, and using this processor's own
+        environment, so that any customized delimiters are honored. Lexing
+        evaluates nothing.
+
+        >>> has_template("SELECT '{{ current_username() }}'")
+        True
+        >>> has_template("{{ dataset(1) }}")
+        True
+        >>> has_template("SELECT '{{1,2},{3,4}}'::int[]")
+        False
+        """
+        try:
+            # The whole stream is consumed before deciding, rather than 
stopping
+            # at the first non-`data` token: `'{{1,2},{3,4}}'` opens like a
+            # template and only turns out not to be one further along, where 
the
+            # lexer gives up.
+            kinds = {kind for _, kind, _ in self.env.lex(sql)}
+        except TemplateSyntaxError:
+            # Jinja does not recognize this as one of its own constructs, so
+            # there is nothing here it would expand.
+            return False
+
+        # SQL that is nothing but a template produces no `data` token at all, 
so
+        # this asks for any other kind rather than for `data` plus another.
+        return bool(kinds - {"data"})

Review Comment:
   Good catch, and taken as stated: the contract is now explicit and the example
   implements it.
   
   `CustomPrestoTemplateProcessor` gets a `has_template` override that reports 
its `$`
   syntax and still defers to Jinja via `super()`. The base docstring names the
   obligation and points at that module, so the next processor with its own 
syntax has
   somewhere to look. There is a test both ways — the custom processor reports
   `$DATE(...)` as a template, and the base processor reports the same SQL as 
having
   none, which is what makes the override necessary.
   
   One thing worth flagging that falls out of the first thread: because the 
render gate
   is gone, `process_template` is now always called, so that processor does get 
to
   expand `$DATE(...)` on the estimate path. The old gate skipped it whenever
   `template_params` was empty, and master still does.



-- 
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]

Reply via email to