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