On Wed, Jan 20, 2016 at 03:32PM, Andrey Gura wrote: > Dmitry, > > We can suggest to Zepplin comunity introduce parameters per > notebook/paragraph that can be passed to interpreter. > > The second option is adding some keywords that can be parsed by > interpreter. > > I think that Val's suggestion is more suitable at this moment.
I actually like Val's ideas as well. What he is proposing is the way to improve UX of the product. See, more and more ppl - especially in this FastData arena - aren't developers. They won't know an exception even if you hit them over the head with one. Hence, whenever an exception is thrown in the UI like Zeppelin, that's the end of the world for most of them. Ideally, we need to go an extra mile to hide all this complexity as much as possible. In fact, the complexity is what killing all these cool technologies. In order to run some simple linear regression calculation, one has to be an expert in Unix, Java, system integration, and god knows what else ;) Cos > On Wed, Jan 20, 2016 at 1:10 AM, Dmitriy Setrakyan <dsetrak...@apache.org> > wrote: > > > Can we just start a different client connection per-notebook? This way user > > can specify different default cache per notebook, no? > > > > Andrey, we already have the explanation for why it does not work. Can you > > provide some ideas on what needs to happen to make it work? > > > > D. > > > > On Tue, Jan 19, 2016 at 11:22 AM, Valentin Kulichenko < > > valentin.kuliche...@gmail.com> wrote: > > > > > Andrey, > > > > > > My answers are inline... > > > > > > On Tue, Jan 19, 2016 at 4:14 AM, Andrey Gura <ag...@gridgain.com> wrote: > > > > > > > Val, > > > > > > > > I have a couple of questions: > > > > > > > > 1. What cache should be used by JDBC driver for query execution when no > > > > cache name in JDBC URL? I see only one option: any user cache. But it > > can > > > > bring some random behavior. Caches can be created/deleted dynamically > > and > > > > JDBC connection can refer to removed cache. > > > > > > > > > > If cache name is not provided in the URL, all cache names have to be > > > provided in the query (except the default cache if it exists). If one of > > > the names refers to non-existing cache, exception will be thrown. Default > > > cache is not different from this standpoint - if the query contains a > > type > > > without cache name specified and default cache doesn't exist, exception > > is > > > thrown as well. > > > > > > > > > > > > > > 2. How user should refer to default cache in queries in case when some > > > non > > > > default cache name used as connection parameter? > > > > > > > > > > This is something that is not possible now anyway, right? Actually, I've > > > never seen an example of the default cache being used, especially if > > > multiple caches are used. So I would not sacrifice usability to support > > > this use case. If one wants to query the default cache, leave it blank in > > > the URL and explicitly specify names of all other caches. > > > > > > > > > > > > > > > > > > > > > > On Tue, Jan 19, 2016 at 12:47 AM, Valentin Kulichenko < > > > > valentin.kuliche...@gmail.com> wrote: > > > > > > > > > I think we can just remove the requirement of having the default > > cache > > > > when > > > > > no cache name is provided in the JDBC URL. I don't see any reason to > > > > refuse > > > > > connection in this case, because if query doesn't properly specify > > > cache > > > > > names for all participating types, the exception will be thrown > > anyway. > > > > > > > > > > Thoughts? > > > > > > > > > > -Val > > > > > > > > > > On Mon, Jan 18, 2016 at 6:35 AM, Andrey Gura <ag...@gridgain.com> > > > wrote: > > > > > > > > > > > Cos, > > > > > > > > > > > > if cache name isn't specified in JDBC URL then default cache will > > be > > > > > used. > > > > > > > > > > > > If default cache isn't created then driver will throw exception > > with > > > > > > "Client is invalid. Probably cache name is wrong" message. > > > > > > > > > > > > You can use workaround and just create default cache. I understand > > > that > > > > > > this solution is not what you want :) > > > > > > > > > > > > I don't have any idea about how to avoid using cache name because > > > > Ignite > > > > > > API requires named cache instance in order to execute query. > > > > > > > > > > > > > > > > > > > > > > > > On Sat, Jan 16, 2016 at 10:44 AM, Konstantin Boudnik < > > c...@apache.org > > > > > > > > > > wrote: > > > > > > > > > > > > > Thanks Andrey. > > > > > > > > > > > > > > I think option one is a bad UX, cause creating an interpreter > > isn't > > > > > > > a) a simple button click (might be improved later on by Z. > > folks) > > > > > > > b) what if I have 25 different caches and the equal number of > > > > > > interpreters > > > > > > > and need to make a change to all of them? > > > > > > > > > > > > > > The second option sounds good, yet the interpreter still needs to > > > > have > > > > > a > > > > > > > particular cache name in the configuration, which now looks weird > > > > > because > > > > > > > I am > > > > > > > working with multiple caches at once. > > > > > > > > > > > > > > It is possible to avoid specifying the cache name all together, > > in > > > > > which > > > > > > > case > > > > > > > a user will have to simply go with what you call cross-cache > > > queries? > > > > > > > > > > > > > > Cos > > > > > > > > > > > > > > On Thu, Jan 14, 2016 at 07:22PM, Andrey Gura wrote: > > > > > > > > Cos, > > > > > > > > > > > > > > > > you have two options in order to create different notebooks for > > > > > > separate > > > > > > > > caches: > > > > > > > > > > > > > > > > 1. You can create separate interpreter with cpecific > > > configuration > > > > > for > > > > > > > each > > > > > > > > notebook. Then you can bind interpreters to notebooks. You can > > > also > > > > > > bind > > > > > > > > many interpreters to oone notebook and use different > > interpreters > > > > in > > > > > > > > different paragraphs. > > > > > > > > > > > > > > > > 2. You can use cross-cache like queries with one interpreter. > > > From > > > > > > docs: > > > > > > > > "In this case, cache names act as schema names in regular SQL. > > > This > > > > > > means > > > > > > > > all caches can be referred by cache names in quotes." > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Andrey Gura > > > > > > GridGain Systems, Inc. > > > > > > www.gridgain.com > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Andrey Gura > > > > GridGain Systems, Inc. > > > > www.gridgain.com > > > > > > > > > > > > > -- > Andrey Gura > GridGain Systems, Inc. > www.gridgain.com
signature.asc
Description: Digital signature
