Re: What is jdbc:ignite:cfg ??

[Andrey Gura <ag...@gridgain.com>]

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

Re: What is jdbc:ignite:cfg ??

[Konstantin Boudnik <co...@apache.org>]

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 <ds...@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.kulichenko@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.kulichenko@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 <
> > cos@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

Re: What is jdbc:ignite:cfg ??

[Andrey Gura <ag...@gridgain.com>]

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 <ds...@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.kulichenko@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.kulichenko@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 <
> cos@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

Re: What is jdbc:ignite:cfg ??

[Dmitriy Setrakyan <ds...@apache.org>]

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.kulichenko@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.kulichenko@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 <cos@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
> >
>

Re: What is jdbc:ignite:cfg ??

[Valentin Kulichenko <va...@gmail.com>]

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.kulichenko@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 <co...@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
>

Re: What is jdbc:ignite:cfg ??

[Andrey Gura <ag...@gridgain.com>]

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.

2. How user should refer to default cache in queries in case when some non
default cache name used as connection parameter?



On Tue, Jan 19, 2016 at 12:47 AM, Valentin Kulichenko <
valentin.kulichenko@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 <co...@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

Re: What is jdbc:ignite:cfg ??

[Valentin Kulichenko <va...@gmail.com>]

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

Re: What is jdbc:ignite:cfg ??

[Andrey Gura <ag...@gridgain.com>]

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

Re: What is jdbc:ignite:cfg ??

[Konstantin Boudnik <co...@apache.org>]

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