Github user sanjaydasgupta commented on the issue:
https://github.com/apache/zeppelin/pull/2502
I would like your views @felixcheung @zjffdu @Tagar on the following
approach to escaping and regex errors etc:
I wish to suggest that no escaping is needed, as the substitution code
kicks in only when 2 conditions are met: (1) the pattern {...} exists in the
command, and (2) the variable named in {...} actually has a mapping in Z. If
the second condition is not met, because a prior z.put(...) has not been
executed for the same variable name, the original command including the {...}
is left unchanged. Since the variable name used is expected to be meaningful,
and is entirely under the end-user's control, it is always possible to avoid
the need for escaping. Leaving the original command unchanged has other
utilities as shown in the examples below.
**Setup**
```
val df = spark.createDataFrame(Seq((1, "one"), (3, "three"),
(Int.MaxValue / 2, "##"), (Int.MaxValue, "####"))).toDF("id", "name")
df.createOrReplaceTempView("name")
z.put("n", 3)
z.put("table", "name")
```
**Trivial Case**
The following SQL command works _normally_ -- performing variable
substitution as expected.
`%sql select * from {table} where id = {n}`
The output has one row: (3, three)
**Unchanged Pattern-Like Construction**
But the following command also works -- with the pattern-like structure
(which is actually a regex passed to _regex_) left unchanged.
`%sql select * from {table} where name rlike '#{2}'`
The output has 2 rows: (1073741823, ##) and (2147483647, ####)
Note that allowing substitution patterns inside quotes is an advantage,
giving us a string-interpolation facility like in Scala (and other languages).
Again, escaping is not required here also as long as the content of {...} is
judiciously chosen.
**One Last Example**
The following example has two {...} structures, the first is part of a
regex, the second is a real pattern.
```
z.put("what", "e")
%sql select * from {table} where name rlike '^.{3}{what}.$'
```
The output has one row: (3, three)
Incomplete patterns are also left unchanged, this could be an advantage for
future embedded mini-languages in the same scope.
Would like to hear your views on the this proposal to not implement escapes
for embedded variable patterns. I only started looking at Zeppelin internals
about 10 days back, so your insight will be very helpful.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
