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