Dima, It is quite common situation that you have cache, but it is not configured to run SQL on it. In this case passing a filter to SCAN query could be an option.
Make sense now? Vova, It is cool to write a kind of LINQ for Ignite, but lets start from filter for SCAN query. What do you think? On Wed, Aug 23, 2017 at 12:25 PM, Dmitriy Setrakyan <dsetrak...@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 <akuznet...@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 < > dsetrak...@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 <voze...@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 < > > akuznet...@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 > > > -- Alexey Kuznetsov
