Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ignite.apache.org
MIME-Version: 1.0
In-Reply-To: <CALOGAoyhsQ=h2POJbb1zyniN+51C_+bWVQQm1FF9M15H4h5Epw@mail.gmail.com>
References: <CA+eZwrFfzcwdV2SHxjVrFqFx5UHPxKScW8=8xHQ8B8rKbYq8LA@mail.gmail.com>
 <CANCAXEF2ue70S9Dbj2Na8xP6vvnkSVO6hQnc71H+cQeJok-1ag@mail.gmail.com> <CALOGAoyhsQ=h2POJbb1zyniN+51C_+bWVQQm1FF9M15H4h5Epw@mail.gmail.com>
From: Sergi Vladykin <sergi.vladykin@gmail.com>
Date: Wed, 12 Apr 2017 14:36:37 +0300
Message-ID: <CA+eZwrGMFV-AK5nyQJ+EXcK01s28BTWzwvW_-fg=h9mW034UBw@mail.gmail.com>
Subject: Re: SQL on PARTITIONED vs REPLICATED cache
To: dev@ignite.apache.org
Content-Type: multipart/alternative; boundary=001a1147ccba787305054cf6a1cf
archived-at: Wed, 12 Apr 2017 11:37:24 -0000

--001a1147ccba787305054cf6a1cf
Content-Type: text/plain; charset=UTF-8

Andrey,

Because if you run query on replicated cache, but select data from a
partitioned table, you will get only a part of the result.

Igor,

You are mostly right, but

1. Performance characteristics may change.
2. Ignite SQL processing pipeline may not support all the stuff in H2 SQL
and fail in some case where it worked previously.

Because of this the change may affect existing applications and I want to
have it in 2.0 to make it legal.

Sergi

2017-04-12 14:10 GMT+03:00 Igor Sapego <isapego@gridgain.com>:

> 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 <
> andrey.mashenkov@gmail.com> 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 <
> sergi.vladykin@gmail.com
> > >
> > 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
> >
>

--001a1147ccba787305054cf6a1cf--