[JBoss JIRA] (ISPN-5222) Perform Remote Filtering/Conversion in a single step
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5222?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5222:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1211944|https://bugzilla.redhat.com/show_bug.cgi?id=1211944] from MODIFIED to ON_QA
> Perform Remote Filtering/Conversion in a single step
> ----------------------------------------------------
>
> Key: ISPN-5222
> URL: https://issues.jboss.org/browse/ISPN-5222
> Project: Infinispan
> Issue Type: Feature Request
> Components: Listeners
> Affects Versions: 7.1.0.Final
> Reporter: Stylianos Koussouris
> Assignee: Galder Zamarreño
> Fix For: 7.2.0.Final
>
>
> I want to have filter and convert take place in one step ie. do filtering and conversion applied to REMOTE LISTENERS in one step
> a) I define CacheEventConverterFactory which implements CacheEventConverterFactory, Serializable
> b) I register on the server org.infinispan.notifications.cachelistener.filter.CacheEventConverterFactory the cache event converter
> which returns (CacheEventConverter<K, V, C>) new SharesDynamicFilterConverter(params);
> c) I then define CacheEventFilterFactory which implements CacheEventFilterFactory, Serializable {
> and returns(CacheEventFilter<K, V>) new SharesDynamicFilterConverter(params);
> d) The CustomeDynamicFilterConverter extends AbstractCacheEventFilterConverter<String, Share, ShareProgress> implements Serializable {
> and has the implementation of
> public Share filterAndConvert(String key, Share oldValue, Metadata oldMetadata, Share newValue, Metadata newMetadata, EventType eventType) {
> e) finally I define a listener binding it to the filter and converter
> @ClientListener(filterFactoryName = "custom-dynamic-filter",
> converterFactoryName = "custom-dynamic-converter",
> includeCurrentState = true)
> and register it along with params for the filter on the client side
> cache.addClientListener(listener, new Object[]{"NYX", 50f}, null);
> The result of this is that certainly both accept and convert methods are run and both call the same filterAndConvert method on SharesDynamicFilterConverter
> However, this is not desirable as I don't want 2 steps which will effectively do the same thing but a single step. TBH I am not happy with the solution but what I did (in absence of better understanding of how to combine the steps -NOTE there is no single Factory for both Converter and Filter and even if it did we would probably have to implement accept & convert inside so the end result would have been the same)
> So what I did was to change the last step
> ie.
> e) finally I define a listener binding ONLY the converter
> @ClientListener(converterFactoryName = "murex-dynamic-converter", includeCurrentState = true)
> and register it along with params ONLY for the converter on the client side
> cache.addClientListener(listener, null, new Object[]{"NYX", 50f});
> This works as it actually does the filter during the convert step BUT is there another way and am I missing something? If not this would be a feature request
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 3 months
[JBoss JIRA] (ISPN-5561) Problem in dealing with the HQL queries that contain string comparison operations, when it involves empty string as an operand
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5561?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5561:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1238866|https://bugzilla.redhat.com/show_bug.cgi?id=1238866] from MODIFIED to ON_QA
> Problem in dealing with the HQL queries that contain string comparison operations, when it involves empty string as an operand
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-5561
> URL: https://issues.jboss.org/browse/ISPN-5561
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Remote Querying
> Affects Versions: 7.2.0.Final
> Environment: Infinispan version: Infinispan 7.2.0-Final
> Operating System: Linux
> Compatibility mode is enabled.
> Indexing is enabled and 'autoconfig' parameter is set to true.
> Reporter: Pavan Kundgol
> Assignee: Adrian Nistor
> Fix For: 8.0.0.Beta2, 7.2.4.Final, 8.0.0.Final
>
>
> When a HQL query that involves string comparison operation with the empty string matching is executed through hot rod client(java), it is resulting in the following error,
> org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[7] returned server error (status=0x85): org.hibernate.search.exception.EmptyQueryException: HSEARCH000146: The query string '' applied on field 'CITY' has no meaningful tokens to be matched. Validate the query input against the Analyzer applied on this field.
> The same problem may also occur when the string matching operation involves a string containing certain special keywords(hibernate search stop words), as operands.
> The problem seems to be assosiated with the the 'hibernate-hql-lucene' parser used by the 'infinispan-remote-query-server' module. The problem here is that the hibernate-hql-lucene parser is translating comparison operations directly into lucene keyword matching operations, irrespective of the field type, though the phrase matching is more appropriate for string fields. This leads to invalid query formation when the field in concern is of type string, and is matched against an empty string(or a string containing one or more hibernate search stop words).
> For example,
> the where condition city='' present in the following HQL query
> select name from com.test.User where city=''
> is tralated to lucene query, the hql-lucene parser is currently translating to
> queryBuilder.keyword().onField("city").matching("").createQuery()
> whereas recommended one is
> queryBuilder.phrase().onField("city").sentence("").createQuery()
> In the former way of translation, Hibernate Search query execution fails due to its usage of standard analyzer while executing the query. Hence, the problem can also be avoided by disabling the standard analyzer while executing the query.
> queryBuilder.keyword().onField("city").ignoreAnalyzer().matching("").createQuery()
> Preferred solution may be to enhance the 'hibernate-hql-lucene' library to do type specific translations, and to specifically translate the string comparison operations of hql query into phrase matching operations of lucene query(instead of keyword matching operations).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 3 months
[JBoss JIRA] (ISPN-5558) DistributedTaskPart.equals() implementation is wrong
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5558?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5558:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1250033|https://bugzilla.redhat.com/show_bug.cgi?id=1250033] from MODIFIED to ON_QA
> DistributedTaskPart.equals() implementation is wrong
> ----------------------------------------------------
>
> Key: ISPN-5558
> URL: https://issues.jboss.org/browse/ISPN-5558
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Distributed Execution and Map/Reduce
> Affects Versions: 7.2.2.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.0.0.Beta1, 7.2.4.Final, 8.0.0.Final
>
>
> {{DistributedExecutorService.submitEverywhere()}} returns a list of futures, one future for each targeted node. Because of how {{DistributedTaskPart.equals()}} is implemented, all the futures in the list appear to be equal, even though their target node is different and their result will also be different.
> The simplest fix would be to remove the equals() and hashCode() overloads from {{DistributedTaskPart}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 3 months
[JBoss JIRA] (ISPN-5388) Optimize redundant predicates (non-indexed query)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5388?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5388:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1211944|https://bugzilla.redhat.com/show_bug.cgi?id=1211944] from MODIFIED to ON_QA
> Optimize redundant predicates (non-indexed query)
> -------------------------------------------------
>
> Key: ISPN-5388
> URL: https://issues.jboss.org/browse/ISPN-5388
> Project: Infinispan
> Issue Type: Enhancement
> Components: Embedded Querying
> Affects Versions: 7.0.0.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 7.2.0.CR1, 7.2.0.Final
>
>
> Cases where predicates evaluate to constant values are already detected and handled. But besides such trivial simplifications we should also try to handle more advanced simplification rules like:
> * X || X => X
> * X && X => X
> * !X || !X => !X
> * !X && !X => !X
> * X || !X => TRUE (tautology)
> * X && !X => FALSE (contradiction)
> (where X is a predicate not a general boolean expression)
> Even further simplification could be achieved if we were able to handle the general case where X is a general boolean expression, but we'll not try that yet for the sake of complexity.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 3 months