[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 Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-5561?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-5561:
--------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/3570, https://github.com/infinispan/infinispan/pull/3572, https://github.com/infinispan/infinispan/pull/3603, https://github.com/infinispan/infinispan/pull/3604 (was: https://github.com/infinispan/infinispan/pull/3570, https://github.com/infinispan/infinispan/pull/3572, https://github.com/infinispan/infinispan/pull/3603)
> 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, 5 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 Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-5561?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-5561:
--------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/3570, https://github.com/infinispan/infinispan/pull/3572, https://github.com/infinispan/infinispan/pull/3603 (was: https://github.com/infinispan/infinispan/pull/3570, https://github.com/infinispan/infinispan/pull/3572)
> 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, 5 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 Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-5561?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-5561:
--------------------------------
Fix Version/s: 8.0.0.Beta2
> 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, 5 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 Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-5561?page=com.atlassian.jira.plugin.... ]
Adrian Nistor reopened ISPN-5561:
---------------------------------
This continues to fail on 7.2.x for remote queries running on a compat mode cache.
Embedded queries on a compat mode cache were fixed by the first PR.
Both cases work on 8.0 branch (the code is quite different).
> 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: 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, 5 months
[JBoss JIRA] (ISPN-5568) KeyAffinityService race condition on view change
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5568?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5568:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> KeyAffinityService race condition on view change
> ------------------------------------------------
>
> Key: ISPN-5568
> URL: https://issues.jboss.org/browse/ISPN-5568
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 5.2.11.Final
> Reporter: Dennis Reed
> Assignee: Bartosz Baranowski
> Fix For: 8.0.0.Beta2, 7.2.4.Final, 5.2.14.Final
>
>
> KeyAffinityService#getKeyForAddress runs in a tight loop looking for keys:
> {noformat}
> queue = address2key.get(address)
> while (result == null)
> result = queue.poll()
> {noformat}
> KeyAffinityService#handleViewChange clears and resets the queue list on membership change:
> {noformat}
> address2key.clear()
> for each address
> map.put(address, new queue)
> {noformat}
> If a view change comes in after getKeyForAddress gets the queue, and the queue is empty, it will get stuck in a tight loop looking at the wrong queue forever while new keys are added to the new queue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (ISPN-5568) KeyAffinityService race condition on view change
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5568?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5568:
----------------------------------
Fix Version/s: 8.0.0.Beta2
7.2.4.Final
5.2.14.Final
> KeyAffinityService race condition on view change
> ------------------------------------------------
>
> Key: ISPN-5568
> URL: https://issues.jboss.org/browse/ISPN-5568
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 5.2.11.Final
> Reporter: Dennis Reed
> Assignee: Bartosz Baranowski
> Fix For: 8.0.0.Beta2, 7.2.4.Final, 5.2.14.Final
>
>
> KeyAffinityService#getKeyForAddress runs in a tight loop looking for keys:
> {noformat}
> queue = address2key.get(address)
> while (result == null)
> result = queue.poll()
> {noformat}
> KeyAffinityService#handleViewChange clears and resets the queue list on membership change:
> {noformat}
> address2key.clear()
> for each address
> map.put(address, new queue)
> {noformat}
> If a view change comes in after getKeyForAddress gets the queue, and the queue is empty, it will get stuck in a tight loop looking at the wrong queue forever while new keys are added to the new queue.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (ISPN-5631) NearCache: ability di wait for other Java HotRod clients to invalidate lazy near cache on remove
by Enrico Olivelli (JIRA)
Enrico Olivelli created ISPN-5631:
-------------------------------------
Summary: NearCache: ability di wait for other Java HotRod clients to invalidate lazy near cache on remove
Key: ISPN-5631
URL: https://issues.jboss.org/browse/ISPN-5631
Project: Infinispan
Issue Type: Feature Request
Components: Core
Affects Versions: 7.2.3.Final
Environment: Java hotrod client/server
Reporter: Enrico Olivelli
When a Java HotRod client invalidates (remove) an entry it is possibile that this action is not propagated with enough speed to other clients due to the async nature of event notifcations used by NearCache, an so it is possibile that another client looks up a stale entry from its near cache.
A typical "writer client" scenario is:
- update the database and commit the transaction
- invalidate the entry which represents the updated (only a "remove")
The "reader" procedure is:
- lookup in the cache (nearcache, backed by the remote Infinispan cluster)
- in case of "cache miss" perform a lookup on the database and write the entry in the cache
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months