By "locally executed callable" I meant something like this: new JdbcCallable(...).call();
So it's not a network call and it's not even going through IgniteCompute. It's just the logic is incapsulated in the callable to support remote execution of the same logic. But anyway, +1 to removing nodeId property. It doesn't make much sense with the new implementation of JDBC. -Val On Mon, Dec 19, 2016 at 10:15 AM, Alexander Paschenko < alexander.a.pasche...@gmail.com> wrote: > When node is local, no network interaction occurs on query send. Would be > shame otherwise :) > > — Alex > 19 дек. 2016 г. 8:36 PM пользователь "Denis Magda" <dma...@apache.org> > написал: > > > Dmitriy, > > > > According to Val and Alex P. explanations this happens when a specific > > node id is set. I got confused by the code flow initially. > > > > — > > Denis > > > > > On Dec 19, 2016, at 9:13 AM, Dmitriy Setrakyan <dsetrak...@apache.org> > > wrote: > > > > > > Thanks, Alex. > > > > > > Can you clarify if the putAll(...) call is made directly, or from > locally > > > executed callable? According to Denis, "even single (non batched) > updates > > > or queries are sent as callables", which should be fixed in my view. > > > > > > D. > > > > > > On Mon, Dec 19, 2016 at 3:32 AM, Alexander Paschenko < > > > alexander.a.pasche...@gmail.com> wrote: > > > > > >> Dima, Val, > > >> > > >> Introduction of updates has not changed public API at all (only > > >> configuration, in some cases), so they work in this respect exactly > > >> like SELECTs - by default they run on client node started by the > > >> driver itself, but can be sent via the same callables mechanism to any > > >> remote node by its id. > > >> > > >> So Dima, you're right, currently it's possible to send query to any > > >> given node. And, at the same time, currently by default everything > > >> works exactly like you want it to - that is, any MERGE, batched or > > >> not, boils down to putAll, and by default this call happens locally. > > >> > > >> - Alex > > >> > > >> 2016-12-17 18:47 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > > >>> On Fri, Dec 16, 2016 at 9:53 PM, Valentin Kulichenko < > > >>> valentin.kuliche...@gmail.com> wrote: > > >>> > > >>>> I'm not sure about updates, but can tell about how selects are > > >> implemented > > >>>> there. Basically, there is an option to execute the query on a > > >> particular > > >>>> node specified by ignite.jdbc.nodeId property. Not sure why we need > > this > > >>>> though, probably it's just leftover from the legacy version of the > > >> driver > > >>>> based on thin client. > > >>>> > > >>>> If the property is set, the callable is sent to a remote node. But > if > > >> it is > > >>>> not, the same callable is created, but it is invoked directly on the > > >>>> embedded client which is the behavior that you expect. And it's the > > >> default > > >>>> one. > > >>>> > > >>>> > > >>> Ouch. If this is the reason, I would drop the nodeId property. I > don't > > >>> think it makes sense and it significantly slows down the > > implementation. > > >>> > > >>> > > >>>> -Val > > >>>> > > >>>> On Fri, Dec 16, 2016 at 7:51 PM, Denis Magda <dma...@apache.org> > > wrote: > > >>>> > > >>>>> Frankly speaking, even single (non batched) updates or queries are > > >> sent > > >>>> as > > >>>>> callables. This is what I see in the code. > > >>>>> No idea what was the reason behind this design. > > >>>>> > > >>>>> Andrey G., Alex P. could you shed a light on this? > > >>>>> > > >>>>> — > > >>>>> Denis > > >>>>> > > >>>>>> On Dec 16, 2016, at 3:08 PM, Dmitriy Setrakyan < > > >> dsetrak...@apache.org> > > >>>>> wrote: > > >>>>>> > > >>>>>> To my understanding, we are implementing JDBC batches by sending a > > >>>>> callable > > >>>>>> to another node. If we already have a client node on the JDBC > driver > > >>>>> side, > > >>>>>> why not just issue a putAll(...) call from the client? > > >>>>>> > > >>>>>> D. > > >>>>>> > > >>>>>> On Fri, Dec 16, 2016 at 3:02 PM, Denis Magda <dma...@apache.org> > > >>>> wrote: > > >>>>>> > > >>>>>>> Dmitriy, > > >>>>>>> > > >>>>>>> JDBC drivers spawns an Ignite client node and uses it for cluster > > >>>>>>> connectivity and queries execution. Queries issued over the JDBC > > >> are > > >>>>> turned > > >>>>>>> into SqlFieldsQueries and sent to the cluster in this form. > > >>>>>>> > > >>>>>>> ODBC driver works in a bit different way. It connects to the > > >> cluster > > >>>> via > > >>>>>>> ODBC processor that needs to be running on one of the nodes: > > >>>>>>> https://apacheignite.readme.io/docs/odbc-driver#cluster- > > >> configuration > > >>>> < > > >>>>>>> https://apacheignite.readme.io/docs/odbc-driver#cluster- > > >> configuration > > >>>>> > > >>>>>>> > > >>>>>>> — > > >>>>>>> Denis > > >>>>>>> > > >>>>>>>> On Dec 16, 2016, at 2:41 PM, Dmitriy Setrakyan < > > >>>> dsetrak...@apache.org> > > >>>>>>> wrote: > > >>>>>>>> > > >>>>>>>> Igniters, > > >>>>>>>> > > >>>>>>>> Can someone explain to me how Ignite executes SQL from JDBC and > > >> ODBC > > >>>>>>>> drivers? Do we start an Ignite client node on the driver side? > Or > > >> do > > >>>> we > > >>>>>>> use > > >>>>>>>> some other protocol to send commands to one of the Ignite nodes? > > >>>>>>>> > > >>>>>>>> Thanks, > > >>>>>>>> D. > > >>>>>>> > > >>>>>>> > > >>>>> > > >>>>> > > >>>> > > >> > > > > >
