Also, is it really a breaking change if the results are wrong? To me it looks more like a bugfix, i.e. you can't break something that does not work properly.
Best Regards, Igor On Wed, Apr 12, 2017 at 2:04 PM, Andrey Mashenkov < [email protected]> wrote: > Sergi, > > How can query to replicated cache leads to to wrong results? > Is it due to we can read backup entries? > > On Wed, Apr 12, 2017 at 12:31 PM, Sergi Vladykin <[email protected] > > > wrote: > > > Guys, > > > > I want to introduce another breaking change for 2.0. > > > > Currently SQL is being processed differently when we call method `query` > on > > partitioned cache and on replicated: on replicated cache we do not do any > > extra processing and execute the query as is on current node. > > > > This behavior historically existed for performance reasons. But it is not > > obvious and leads to wrong query results. This issue becomes even more > > creepy with JDBC and ODBC drivers. > > > > In 2.0 I want to execute all the SQL queries the same way through the > whole > > processing pipeline to guaranty the correct result irrespectively to the > > cache that was the query originator. > > > > To be able to have the old behavior (skip all the preprocessing and run > > query on current node) add a flag isReplicatedOnly() on SqlQuery and > > SqlFieldsQuery. It will be disabled by default and if one knows that the > > only replicated tables participate in a query, then he can enable it for > > better performance. > > > > Sergi > > > > > > -- > Best regards, > Andrey V. Mashenkov >
