No, it is not exposed to public API. Didn't want to add another flag to SqlFieldsQuery.
вс, 15 окт. 2017 г. в 0:19, Dmitriy Setrakyan <dsetrak...@apache.org>: > Vova, is there any way to enable this flag from API, without using JDBC > driver? > > On Sat, Oct 14, 2017 at 1:17 PM, Vladimir Ozerov <voze...@gridgain.com> > wrote: > > > Dmitry, > > > > Corretct. Example: jdbc:ignite:thin:// > 192.168.0.1?skipReducerOnClient=true > > > > On Fri, Oct 13, 2017 at 8:16 PM, Dmitriy Setrakyan < > dsetrak...@apache.org> > > wrote: > > > > > Vova, > > > > > > Just to make sure, we are not adding a new configuration property, > right? > > > Is this just a JDBC connection flag we are discussing? If yes, can you > > > please provide an example of the JDBC connection string? > > > > > > D. > > > > > > On Fri, Oct 13, 2017 at 9:57 AM, Denis Magda <dma...@apache.org> > wrote: > > > > > > > Vladimir, > > > > > > > > > "inPlaceUpdate" is not very good candidate because there are a lot > of > > > > other > > > > > "in place update" optimizations in RDBMS word, and most of them > > relates > > > > to > > > > > in-place update of some value in the data page. I am afraid users > > will > > > be > > > > > confused with this name. > > > > > > > > I’m not insisting on this name but that’s neither system nor global > > > > configuration property. The property scope is defined by the > drivers’s > > > > boundaries. So if to think of it as of a hint for the drivers it > > doesn’t > > > > sound too generic. > > > > > > > > Anyway, “reducer” versions sound too low-level and, probably, I would > > > > leave the current “updateOnServer” as is. > > > > > > > > — > > > > Denis > > > > > > > > > On Oct 13, 2017, at 12:02 AM, Vladimir Ozerov < > voze...@gridgain.com> > > > > wrote: > > > > > > > > > > Denis, > > > > > > > > > > In future SQL transactional protocol will do all updates "in place" > > > > instead > > > > > of passing it to the client. This is the only possible way to > perform > > > > large > > > > > updates without killing the client with OOME. > > > > > "inPlaceUpdate" is not very good candidate because there are a lot > of > > > > other > > > > > "in place update" optimizations in RDBMS word, and most of them > > relates > > > > to > > > > > in-place update of some value in the data page. I am afraid users > > will > > > be > > > > > confused with this name. > > > > > > > > > > On Fri, Oct 13, 2017 at 2:15 AM, Denis Magda <dma...@apache.org> > > > wrote: > > > > > > > > > >> How about “inPlaceUpdate”? > > > > >> > > > > >> A side note, I see the feature documented for ODBC in our hidden > SQL > > > > >> domain [1]. But it’s missing for JDBC. Did we forget to update the > > > JDBC > > > > >> docs? > > > > >> > > > > >> [1] https://apacheignite-sql.readme.io/docs/connection- > > > > >> string-and-dsn#section-supported-arguments > > > > >> > > > > >>> > > > > >>> Unfortunately we cannot enable this mode by default, because it > is > > > > still > > > > >> a > > > > >>> bit raw and there is a risk of regressions. Also when > transactional > > > SQL > > > > >> is > > > > >>> ready this feature will make no sense in TX mode. For this reason > > we > > > > >>> disable it by default for now > > > > >> > > > > >> > > > > >> Does it mean that this kind of optimization is not feasible for > > > > >> transaction SQL or it will be just solved differently? Just trying > > to > > > > grasp > > > > >> if we are going to drop it after the TX SQL release. > > > > >> > > > > >> — > > > > >> Denis > > > > >> > > > > >>> On Oct 11, 2017, at 11:45 PM, Vladimir Ozerov < > > voze...@gridgain.com> > > > > >> wrote: > > > > >>> > > > > >>> Igniters, > > > > >>> > > > > >>> We prepared optimization of DML processing. Instead of passing > all > > > data > > > > >>> being updated through the client node, now we can optionally send > > SQL > > > > >>> statement to data nodes and perform update locally. This could > > > greatly > > > > >>> improve performance of certain DML operations. > > > > >>> > > > > >>> Unfortunately we cannot enable this mode by default, because it > is > > > > still > > > > >> a > > > > >>> bit raw and there is a risk of regressions. Also when > transactional > > > SQL > > > > >> is > > > > >>> ready this feature will make no sense in TX mode. For this reason > > we > > > > >>> disable it by default for now. > > > > >>> > > > > >>> It will be possible to enable it from JDBC/ODBC drivers using a > > flag. > > > > >>> Question - how to name this flag? Current name is > > > "*updateOnServer*". I > > > > >>> doesn't like it much, but cannot do better. Please share other > > ideas. > > > > >>> > > > > >>> - "distributedDml"? No, every operation is distributed. > > > > >>> - "serverDml"? > > > > >>> > > > > >>> Vladimir. > > > > >> > > > > >> > > > > > > > > > > > > > >
