Vova, I think you are suggesting an API-based query language. This seems like a huge undertaking for a very questionable benefit, given that SQL is way more flexible.
I would rather fix the H2 GC and optimizer problems. D. On Wed, Aug 23, 2017 at 12:01 AM, Vladimir Ozerov <voze...@gridgain.com> wrote: > 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 <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 > > > > > >
