[JBoss JIRA] (ISPN-5715) Perform AST caching for DSL queries with parameters
by Prashant Thakur (JIRA)
[ https://issues.jboss.org/browse/ISPN-5715?page=com.atlassian.jira.plugin.... ]
Prashant Thakur commented on ISPN-5715:
---------------------------------------
Two more concerns were observed along with storing Parsing results
1) Reflection takes too much time in Object Filter
2) With increase in number of entries the time spent in buildSearcher increases almost linearly, Hence a ReaderStrategy needs to be defined which would be interacting with Index Writer events and close only when entities are changed.
We are currently working on 2) and will share code once ready.
> Perform AST caching for DSL queries with parameters
> ---------------------------------------------------
>
> Key: ISPN-5715
> URL: https://issues.jboss.org/browse/ISPN-5715
> Project: Infinispan
> Issue Type: Feature Request
> Components: Embedded Querying, Remote Querying
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 8.1.0.Final
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ISPN-5553) Functional Java 8 API
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5553?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-5553:
-------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/3571, https://github.com/infinispan/infinispan/pull/3677 (was: https://github.com/infinispan/infinispan/pull/3571)
> Functional Java 8 API
> ---------------------
>
> Key: ISPN-5553
> URL: https://issues.jboss.org/browse/ISPN-5553
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 8.0.0.CR1, 8.0.0.Final
>
>
> Infinispan 8 is baselining on Java 8 and that enables a more advanced , functional, APIs to be built instead of relying on the traditional Map-like APIs. Such APIs, taking lambda functions, can improve on the current APIs in the following way:
> * Being able to provide a write operation, where the operation is defined as a lambda, better enables conditional (CAS) like operations that are based in functions other than equality, e.g. version equality. If this functions can be executed atomically, they provide a better solution for Hot Rod version-based replace operations that currently can cause some weird behaviour (ISPN-4972)
> * When operations are defined as lambdas, it's easier to move towards a model that tracks/replicates operations leading to state, rather than replicating state itself. This makes it easier to implement more-efficiently replicated alternative data structures, such as counts, lists...etc, and paths the way towards CRDTs, particularly CmRDT (Commutative Replicated Data Types) or operation-based CRDTs.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ISPN-5704) Enhancements for Functional Map API
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5704?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-5704:
-----------------------------------
Description:
List of enhancements that didn't make it into 8.0:
* Transaction support.
* Verify locks are acquired for all operations (once tx is in place, locks can be checked easily)
* Complete persistence support (remove many returning previous, put many returning previous, remove many)
* Replication of per-invocation parameters.
* Port mode *Becoming*Test to functional APIs, and expand on testing other functional APIs.
* Test interoperability with cache, e.g. cache put with lifespan can be retrieved via functional map with lifespan, and viceversa
* Test compatibility mode
* Add more listener events: activation, passivation and expiration.
* Use check isLocal instead of `e == null` in command impls
* Fix branch skip issue (see previous PR: https://github.com/infinispan/infinispan/pull/3571)
* Add externalizers for primitive versions of Optional.
* ValueMatcherMode indexes in MarshallableFunctionExternalizers should be based on {{ordinal()}} calls to annotation. Also, could the core's enumeration use the annotations defined in commons?
was:
List of enhancements that didn't make it into 8.0:
* Transaction support.
* Verify locks are acquired for all operations (once tx is in place, locks can be checked easily)
* Complete persistence support (remove many returning previous, put many returning previous, remove many)
* Replication of per-invocation parameters.
* Port mode *Becoming*Test to functional APIs, and expand on testing other functional APIs.
* Test interoperability with cache, e.g. cache put with lifespan can be retrieved via functional map with lifespan, and viceversa
* Test compatibility mode
* Add more listener events: activation, passivation and expiration.
* Use check isLocal instead of `e == null` in command impls
* Fix branch skip issue (see previous PR: https://github.com/infinispan/infinispan/pull/3571)
* Add externalizers for primitive versions of Optional.
> Enhancements for Functional Map API
> -----------------------------------
>
> Key: ISPN-5704
> URL: https://issues.jboss.org/browse/ISPN-5704
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 8.1.0.Final
>
>
> List of enhancements that didn't make it into 8.0:
> * Transaction support.
> * Verify locks are acquired for all operations (once tx is in place, locks can be checked easily)
> * Complete persistence support (remove many returning previous, put many returning previous, remove many)
> * Replication of per-invocation parameters.
> * Port mode *Becoming*Test to functional APIs, and expand on testing other functional APIs.
> * Test interoperability with cache, e.g. cache put with lifespan can be retrieved via functional map with lifespan, and viceversa
> * Test compatibility mode
> * Add more listener events: activation, passivation and expiration.
> * Use check isLocal instead of `e == null` in command impls
> * Fix branch skip issue (see previous PR: https://github.com/infinispan/infinispan/pull/3571)
> * Add externalizers for primitive versions of Optional.
> * ValueMatcherMode indexes in MarshallableFunctionExternalizers should be based on {{ordinal()}} calls to annotation. Also, could the core's enumeration use the annotations defined in commons?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months
[JBoss JIRA] (ISPN-5705) Execution of a Hibrid Query that involves certain specific 'OR' conditions returns incorrect results
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5705?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-5705:
------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Execution of a Hibrid Query that involves certain specific 'OR' conditions returns incorrect results
> ----------------------------------------------------------------------------------------------------
>
> Key: ISPN-5705
> URL: https://issues.jboss.org/browse/ISPN-5705
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 8.0.0.Beta3
> Environment: Hibrid Query that includes 'OR' condition fails in certain specific cases
> Reporter: Prashanth Reddy
> Assignee: Adrian Nistor
> Priority: Critical
> Fix For: 8.0.0.Final
>
> Attachments: BooleShannonExpansion.diff
>
>
> The hibrid query, mentioned below produces wrong results, upon execution.
> SELECT p.ID, p.NAME FROM com.testapp.Person p WHERE p.IS_ACTIVE=1 AND (p.CITY='city1' OR p.CITY='city2') AND p.ID>1000
> for the Data:
> ID | NAME | CITY | IS_ACTIVE
> -------------------
> 2001 person1 city1 1
> 2002 person1 city1 1
> 2003 person1 city1 1
> 2004 person1 city1 0
> 2005 person1 city2 1
> 2006 person1 city2 1
> 2007 person1 city3 0
> 2008 person1 city3 1
> Indexed fields: ID, NAME, CITY
> Non-indexed fields: IS_ACTIVE
> Query execution returned 0 number of rows, whereas expected result count is 5.
> After some analysis root cause for the problem has been found, and the details are as follows,
> As a part of separating the query that depends on indexed fields, using boole shannon algorithm, it has first extraced out the condition 'IS_ACTIVE=1' (as it deals with non-indexed fields).
> Assuming four boolean conditions as c1, c2, c3, c4, where c1 represents the condition 'IS_ACTIVE=1'
> f(c1,c2,c3,c4) = c1.f(1, c2, c3, c4) + c1`.f`(0, c2, c3, c4)
> consider
> e1=f(1, c2, c3, c4)
> e2=f`(0, c2, c3, c4)
> which have to be used for constructing the lucene query, for further transformation.
> After splitting as per the above logic, it is trying to optimize the resultant subconditions(e1, e2), so as to reduce the number of conditions to be evaluated. One such optimization that has been found is that when there is a conjuction operation between two comparison predicates dealing with same lvalues(here, same fields), but with the different rvalues(here, constants), it has been optimized to replace it with a contradiction(constant false boolean expression). As we know, this optimization is applicable only for conjuction. But, the same is applied even for the disjuction, which is causing the above mentioned problem.
> For example,
> condition p.CITY='city1' AND p.CITY='city2'
> can be replaced with CONTRADICTION(BooleanConst.FALSE)
> But, the same cannot be done, for
> condition p.CITY='city1' OR p.CITY='city2'
> Following change may correct the problem.
> File: infinispan-8.0.0.Beta3/object-filter/src/main/java/org/infinispan/objectfilter/impl/syntax/BooleShannonExpansion.java:155
> diff:
> @@ -152,7 +152,7 @@
> }
> }
> }
> - PredicateOptimisations.optimizePredicates(newChildren, true);
> + PredicateOptimisations.optimizePredicates(newChildren, false);
> if (newChildren.size() == 1) {
> return newChildren.get(0);
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
8 years, 10 months