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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > 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 < > [email protected] > > > > > > 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 >
