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 suggesti
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,
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
Andrey,
My answers are inline...
On Tue, Jan 19, 2016 at 4:14 AM, Andrey Gura 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 rand
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
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.
T
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
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 sound
Dima,
because notebook doesn't have any settings for it.
On Thu, Jan 14, 2016 at 11:30 PM, Dmitriy Setrakyan
wrote:
> Andrey, I am still a bit unclear. Why not have ability to specify a default
> cache per notebook, not per-interpreter?
>
> On Thu, Jan 14, 2016 at 8:42 AM, Andrey Gura wrote:
>
Andrey, I am still a bit unclear. Why not have ability to specify a default
cache per notebook, not per-interpreter?
On Thu, Jan 14, 2016 at 8:42 AM, Andrey Gura wrote:
> Hello,
>
> JFYI, I created ticket as result of this discussion:
> https://issues.apache.org/jira/browse/IGNITE-2382
>
>
>
> O
Hello,
JFYI, I created ticket as result of this discussion:
https://issues.apache.org/jira/browse/IGNITE-2382
On Thu, Dec 10, 2015 at 10:29 PM, Dmitriy Setrakyan
wrote:
> Andrey,
>
> I agree on both points. However, I still think that we should provide
> sample step-by-step guide with a sampl
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 interpret
Having docs is great, but if we can get away with zero-config - that should be
done for sure. While on the 0-config point: when dealing with an normal RDBMS
one can browse the schema and list the tables in it. In Ignite, the cache name
(ie table name) should be explicitly listed. While I think I un
Andrey,
I agree on both points. However, I still think that we should provide
sample step-by-step guide with a sample configuration. This configuration
should include a couple of data types, like Person and Organization, define
indexes for them, etc.
This guide should include:
1. Start Ignite Se
I didn't think that we should force client mode at moment of
implementation. But I can't provide any reason not to do it.
So we need two small improvements to JDBC driver:
1. Always force client mode.
2. Use default configuration in cases when user did't specify any URL. This
configuration should
Usually you connect to cluster when user defined types used. So p2p class
loading is requred in order to executes queries. Am I Wrong?
I'll remove TCP discovery with multicast from example.
On Thu, Dec 10, 2015 at 3:01 AM, Dmitriy Setrakyan
wrote:
> Thanks Andrey!
>
> Why are we enabling peer
On Wed, Dec 9, 2015 at 10:04 PM, Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:
> Actually, why don't we set it automatically? It doesn't make much sense to
> have a server node in a JDBC driver.
>
Completely agree.
>
> -Val
>
> On Wed, Dec 9, 2015 at 10:02 PM, Dmitriy Setrakyan
>
Actually, why don't we set it automatically? It doesn't make much sense to
have a server node in a JDBC driver.
-Val
On Wed, Dec 9, 2015 at 10:02 PM, Dmitriy Setrakyan
wrote:
> On Wed, Dec 9, 2015 at 6:46 PM, Konstantin Boudnik wrote:
>
> > On Wed, Dec 09, 2015 at 04:01PM, Dmitriy Setrakyan wr
On Wed, Dec 9, 2015 at 6:46 PM, Konstantin Boudnik wrote:
> On Wed, Dec 09, 2015 at 04:01PM, Dmitriy Setrakyan wrote:
> > Thanks Andrey!
> >
> > Why are we enabling peer class loading for the JDBC driver in your
> example?
> > To my knowledge, we are not deploying any classes, are we? Also, the T
On Wed, Dec 09, 2015 at 04:01PM, Dmitriy Setrakyan wrote:
> Thanks Andrey!
>
> Why are we enabling peer class loading for the JDBC driver in your example?
> To my knowledge, we are not deploying any classes, are we? Also, the TCP
> discovery with multicast is the default, so no reason to specify i
Thanks Andrey!
Why are we enabling peer class loading for the JDBC driver in your example?
To my knowledge, we are not deploying any classes, are we? Also, the TCP
discovery with multicast is the default, so no reason to specify it either.
It seems that the only properly required is clientMode=tr
Yup, much better now! Thanks man!
On Wed, Dec 09, 2015 at 07:54PM, Andrey Gura wrote:
> Configuration sample added.
>
> On Tue, Dec 8, 2015 at 10:20 PM, Dmitriy Setrakyan
> wrote:
>
> > Thanks Andrey!
> >
> > In my view, we should also provide a sample XML configuration file,
> > especially giv
Configuration sample added.
On Tue, Dec 8, 2015 at 10:20 PM, Dmitriy Setrakyan
wrote:
> Thanks Andrey!
>
> In my view, we should also provide a sample XML configuration file,
> especially given that we refer to it in the sample URL.
>
> D.
>
> On Tue, Dec 8, 2015 at 10:17 AM, Andrey Gura wrote:
Thanks Andrey!
In my view, we should also provide a sample XML configuration file,
especially given that we refer to it in the sample URL.
D.
On Tue, Dec 8, 2015 at 10:17 AM, Andrey Gura wrote:
> Done. I hope that is more clear now.
>
> On Tue, Dec 8, 2015 at 1:14 AM, Dmitriy Setrakyan
> wrot
Done. I hope that is more clear now.
On Tue, Dec 8, 2015 at 1:14 AM, Dmitriy Setrakyan
wrote:
> On Mon, Dec 7, 2015 at 10:17 AM, Andrey Gura wrote:
>
> > Cos,
> >
> > sepcifies configuration file for Ignite client node that
> will
> > be started during connection establishing by JDBC driver. S
On Mon, Dec 7, 2015 at 10:17 AM, Andrey Gura wrote:
> Cos,
>
> sepcifies configuration file for Ignite client node that will
> be started during connection establishing by JDBC driver. So this file
> should be available for JDBC driver client.
>
Andrey, should this be documented here?
https://a
Cos,
sepcifies configuration file for Ignite client node that will
be started during connection establishing by JDBC driver. So this file
should be available for JDBC driver client.
On Mon, Dec 7, 2015 at 8:59 PM, Konstantin Boudnik wrote:
> Thanks Andrey!
>
> Still a bit unclear: the doc says
Thanks Andrey!
Still a bit unclear: the doc says
" is required and represents any valid URL which points to Ignite
configuration file"
So, that's server side URL then, something like
jdbc:ignite:cfg:///etc/ignite/conf/default-config.xml
assuming that server nodes have said configuration un
Cos,
JDBC driver was reworked in order to use Ignite client node instead of
Ignite Java client. It gives better performance. So now JDBC dirver uses
Ignite xml configuration file using jdbc:ignite:cfg protocol. See
documentation for version 1.4
https://apacheignite.readme.io/v1.4/docs/jdbc-driver
Guys, I am looking into [1] and see a reference to
ignite.jdbc.url = "jdbc:ignite:cfg://"
So, I am curious if there's a way to fetch node's config via JDBC somehow? Or
this is just a simple error in the doc, which needs to be fixed?
Would appreciate the insight from the team. Thanks!
Cos
[1]
30 matches
Mail list logo
