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