Dima, Yes, in future releases we will enable it by default. New TX protocol will work in pretty much the same way.
On Fri, Oct 13, 2017 at 4:57 AM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > On Wed, 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. > > > This feature should be enabled by default, as it should not be up to a user > to decide when to use it. Whatever name we come up with now will be > temporary, so it does not really matter. > > 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. > > > > We should figure out a proper way to use it in transactional mode. I am > sure we can, once we think it through. But even if we cannot, the system > should automatically decide when to use this optimization and when not to > use it. > > > > > > 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"? > > > > In my view, we should come up with a generic enable/disable switch for all > experimental features. For example, > "experimental=feature1,feature2,feature3". Then, once a feature stops > being > experimental, we simply enable it in the system via normal Ignite > configuration or by default. >
