ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vladimir Ozerov <voze...@gridgain.com>
Subject Re: Criteria query to web console
Date Wed, 23 Aug 2017 07:01:43 GMT
Dima,

Personally I do not know why Yakov and Alex needed it on a WebConsole. But
as a whole ability to construct arbitrary queries through API is a
killer-feature. First, it is much more convenient for users - you do not
need to hard-code strings, you have full API support - refactoring, code
completion, etc., you will never meet unsupported features (like on our
SQL), etc. The most widely known example is LINQ in .NET - nobody wants to
use our SQL, they use LINQ because it is super-convenient. Hazelcast goes
in the same direction and this is right decision.

Another major point is performance. With current state of affairs we
already can make simple EL-queries (similar to "SELECT a FROM b WHERE c=?")
times more efficient than our SQL, because we will bypass a lot heavy
places such as parsing, dumb H2 optimizer, inefficient H2 API producing
garbage, etc..

Vladimir.

On Wed, Aug 23, 2017 at 8:25 AM, Dmitriy Setrakyan <dsetrakyan@apache.org>
wrote:

> I still don't get it. If I need a filter, then I will just use SQL.
>
> On Tue, Aug 22, 2017 at 8:46 PM, Alexey Kuznetsov <akuznetsov@gridgain.com
> >
> wrote:
>
> > Vladimir,
> >
> > Thanks  for your feedback, I think it make sense.
> >
> > Dmitriy,
> >
> > No, critera based filter wull work only for ScanQuery, see ScanQuery
> > constructor with filter:
> >     ScanQuery(@Nullable IgniteBiPredicate<K, V> filter)
> >
> > This should be implemented with buider, smth like this:
> >
> > CriteriaBuilder builder = new CriteriaBuilder();
> >
> > IgniteBiPredicate filter =
> > builder.add(TCriteria(...)).and(TCriteria(...)).or(
> TCriteria(...)).andNot(
> > TCriteria(...)).build();
> >
> > ScanQuery q = new ScanQuery(filter);
> >
> > cache.query(q)....
> >
> > And we could have nice Web UI for this: IgniteBiPredicate filter =
> > builder.add(TCriteria(...)).and(TCriteria(...)).or(
> TCriteria(...)).andNot(
> > TCriteria(...)).build();
> >
> >
> > On Wed, Aug 23, 2017 at 8:46 AM, Dmitriy Setrakyan <
> dsetrakyan@apache.org>
> > wrote:
> >
> > > I am a bit confused. How about "select * from SomeTable where
> myCriteria
> > >
> > > 1"?
> > >
> > > On Tue, Aug 22, 2017 at 9:16 AM, Vladimir Ozerov <vozerov@gridgain.com
> >
> > > wrote:
> > >
> > > > My strong recommendation here is to think carefully of all potential
> > use
> > > > cases first, so that we end up with consistent and extendable API.
> This
> > > > filters could be useful for both ScanQuery, platforms and 3-rd party
> > > > clients. Hence, "query" package is definitely not the right place. I
> > > would
> > > > said that this is our "expression language" or so, and put these
> > filters
> > > to
> > > > "org.apache.ignite.el" package.
> > > >
> > > > On Tue, Aug 22, 2017 at 6:30 PM, Alexey Kuznetsov <
> > akuznetsov@apache.org
> > > >
> > > > wrote:
> > > >
> > > > > Hi, All.
> > > > >
> > > > > Recently, Yakov opened issue:  Criteria query to web console [1]
> > > > >
> > > > > We can create criteria based filter that could be passed to
> ScanQuery
> > > > over
> > > > > BinaryObjecs.
> > > > >
> > > > > I think it make sens to implement this filter as first-class
> citizen
> > > > > of org.apache.ignite.cache.query package and also support it from
> Web
> > > > > Console. But it could be re-used directly from code also.
> > > > >
> > > > > I think that we should implement a set of predicates to support
> AND,
> > OR
> > > > and
> > > > > NOT logical operations to group several predicates.
> > > > >
> > > > > We should support following operations:
> > > > > Numbers:  ==, <, >, <=, >=, !=
> > > > > Strings: equals, startsWith, endsWith, contains, matchRegExp (and
> > also
> > > > with
> > > > > IgnoreCase mode).
> > > > > Dates: ==, <, >, <=, >=, !=, between
> > > > > All: isNull, isDefined*
> > > > >
> > > > > *isDefined - Here I mean a check that some property is present in
> > > > > BinaryObject
> > > > >
> > > > > What do you think?
> > > > > If I missed some operations, please advice what could be added.
> > > > >
> > > > > Also, I think that a separate issue should be created for such
> "rules
> > > > > engine for BinaryObjects".
> > > > > Make sense?
> > > > >
> > > > >
> > > > > [1] https://issues.apache.org/jira/browse/IGNITE-6132
> > > > >
> > > > >
> > > > > --
> > > > > Alexey Kuznetsov
> > > > >
> > > >
> > >
> >
> >
> >
> > --
> > Alexey Kuznetsov
> > GridGain Systems
> > www.gridgain.com
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message