I think we can use default interpreter which would set when users create a note. It's a bit natural and won't break current behaviours
On Sat, Sep 22, 2018 at 8:16 PM, andreas.we...@gmail.com < andreas.we...@gmail.com> wrote: > I agree with Jongyoul. Changing the default interpreter in an existing > note is vital, especially when a note has plenty of paragraphs. > > E.g. we are using spark interpreter per Org Unit and also for different > sizings. > > Our end users are using the respective Spark Interpreter just by setting > it to default and then using short syntax: %pyspark, %sql or %spark . After > some time, they want to change the default interpreter to use a different > Spark Executor Sizings or hand a note over to another Org Unit. > > In that situation changing full qualified names in ALL paragraphs is not > really feasible IMHO. > > As changing the default paragraph in existing notes is now still missing > in master branch, is there already a Jira Issue filed? I couldn't find it > in the umbrella story: https://issues.apache.org/jira/browse/ZEPPELIN-3594 > > This issue is currently blocking us from early testing the master branch > with productive use cases. > > Thanks > Andreas > > On 2018/07/06 07:53:04, Jeff Zhang <zjf...@gmail.com> wrote: > > We already allow setting default interpreter when creating note. Another > > way to set default interpreter is to reorder the interpreter setting > > binding in note page. > > > > But personally I don't recommend user to use short interpreter name > because > > of default interpreter. 2 Reaons: > > 1. It introduce in-accurate info. e.g. In our product, we have 2 spark > > interpreters (`spark`: for spark 1.x & `spark2` for spark 2.x). Then > user > > often specify `%spark` for spark interpreter. But it could mean both > > `%spark.spark` and `%spark2.spark`, So usually it is very hard to tell > > what's wrong when user expect to work spark2 but actually he still use > > spark 1.x. So usually we would recommend user to specify the full > qualified > > interpreter name. Just type several more characters which just cost 2 > > seconds but make it more clear and readable. > > 2. Another issue is that interpreter binding is stored in > interpreter.json, > > that means if they export this note to another zeppelin instance, the > > default interpreter won't work. > > > > So I don't think setting default interpreter via interpreter binding is > > valuable for users. If user really want to do that, I would suggest to > > store it in note.json instead of interpreter.json > > > > > > Jongyoul Lee <jongy...@gmail.com>于2018年7月6日周五 下午3:36写道： > > > > > There are two purposes of interpreter binding. One is what you > mentioned > > > and another one is to manage a default interpreter. If we provide a > new way > > > to set default interpreter, I think we can remove them :-) We could set > > > permissions in other ways. > > > > > > Overall, +1 > > > > > > On Fri, Jul 6, 2018 at 4:24 PM, Jeff Zhang <zjf...@gmail.com> wrote: > > > > > >> Hi Folks, > > >> > > >> I raise this thread to discuss whether we need the interpreter > binding. > > >> Currently when user create notes, they have to bind interpreters to > their > > >> notes in note page. Otherwise they will hit interpreter not found > issue. > > >> Besides that in zeppelin server side, we maintain the interpreter > binding > > >> info in memory as well as in interpreter.json. > > >> > > >> IMHO, it is not necessary to do interpreter binding. Because it just > add > > >> extra burden to maintain the interpreter binding info in zeppelin > server > > >> side, and doesn't introduce any benefits. The only benefit is that we > will > > >> check whether user have permission to use this interpreter, but > actually > > >> zeppelin will check the permission when running paragraph, so I don't > think > > >> we need to introduce interpreter binding just for this kind of > permission > > >> check that we will do later. > > >> > > >> So overall, I would suggest to remove interpreter binding feature. > What > > >> do you think ? > > >> > > > > > > > > > > > > -- > > > 이종열, Jongyoul Lee, 李宗烈 > > > http://madeng.net > > > > > > -- 이종열, Jongyoul Lee, 李宗烈 http://madeng.net
