[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 Pavan Kundgol (JIRA)
[ https://issues.jboss.org/browse/ISPN-5561?page=com.atlassian.jira.plugin.... ]
Pavan Kundgol commented on ISPN-5561:
-------------------------------------
[~anistor]
Thanks for the quick response.
The problem seems to be at the HIbernate Search level. Irrespective of the interface that is used to contruct the query and the infinispan mode(embedded or hotrod(compatibility enabled or disbled)) that is configured, the problem may(I originally faced the problem, in hotrod mode with compatibility enabled) occur, if the final lucene query involves at least one empty string matching operation.
As you indicated, even though the field is configured not to be analyzed (analyze = Analyze.NO), at the time of querying it is applying an analyzer(probably StandardAnalyzer), which is causing the actual problem. I suspect it is not the expected behavior of hibernated search functionality. Though the problem can be resolved by enhancing the 'hibernate-hql-lucene' library, as discussed in the issue description, the problem itself may dissappear(without any changes to that library), if this behavior(applying analyzer during the query operation, for a non-analyzed field) is not the actual expected behavior from the HIbernate Search, and is corrected appropriately.
In any case, it is better to translate string matching operations to lucene phrase matching operations, rather than the same into lucene keyword matching operations, and hence still it is better to update 'hibernate-hql-lucene' library, appropriately.
> 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.3.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
[JBoss JIRA] (ISPN-5558) DistributedTaskPart.equals() implementation is wrong
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5558?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5558:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3551
> 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.3.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
[JBoss JIRA] (ISPN-5558) DistributedTaskPart.equals() implementation is wrong
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5558?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5558:
----------------------------------
Fix Version/s: 7.2.3.Final
> 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.3.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
[JBoss JIRA] (ISPN-3940) Fine-grained authorization
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-3940?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-3940:
----------------------------------
Description:
Add a way to set ACL per-entry, storing it in some additional security metadata so that only users belonging to certain roles can access it.
was:Add
> Fine-grained authorization
> --------------------------
>
> Key: ISPN-3940
> URL: https://issues.jboss.org/browse/ISPN-3940
> Project: Infinispan
> Issue Type: Sub-task
> Components: Core, Security
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 8.1.0.Final
>
>
> Add a way to set ACL per-entry, storing it in some additional security metadata so that only users belonging to certain roles can access it.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years
[JBoss JIRA] (ISPN-5544) Deprecate eager near caching
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5544?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5544:
----------------------------------
Status: Open (was: New)
> Deprecate eager near caching
> ----------------------------
>
> Key: ISPN-5544
> URL: https://issues.jboss.org/browse/ISPN-5544
> Project: Infinispan
> Issue Type: Task
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 8.0.0.Beta1, 8.0.0.Final
>
>
> In it's current form, eager near caching can lead the server to run out of direct memory, see ISPN-5523. The reason that's happening is because we're having to send events containing keys + values for each put() operation, indiscriminately to clients. So, regardless of what the client stores in the near cache, the client receives key+value information for all keys, as each key is created/modified, and this is having a big toll on the capabilities of the server to push those events to clients.
> So, we have decided to deprecate eager near caching in Infinispan 8.0, and we'll remove it completely for Infinispan 9.0.
> Lazy near caching still remains and works well because events are smaller since no value is sent to clients. Lazy near caching is still indiscriminate but we have plans to make it more selective, so that for example, only modified/removed events are sent for those keys that are stored in the client near cache, which would reduce traffic considerably (new jira to be created).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years
[JBoss JIRA] (ISPN-5544) Deprecate eager near caching
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-5544?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-5544:
----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/3545
> Deprecate eager near caching
> ----------------------------
>
> Key: ISPN-5544
> URL: https://issues.jboss.org/browse/ISPN-5544
> Project: Infinispan
> Issue Type: Task
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 8.0.0.Beta1, 8.0.0.Final
>
>
> In it's current form, eager near caching can lead the server to run out of direct memory, see ISPN-5523. The reason that's happening is because we're having to send events containing keys + values for each put() operation, indiscriminately to clients. So, regardless of what the client stores in the near cache, the client receives key+value information for all keys, as each key is created/modified, and this is having a big toll on the capabilities of the server to push those events to clients.
> So, we have decided to deprecate eager near caching in Infinispan 8.0, and we'll remove it completely for Infinispan 9.0.
> Lazy near caching still remains and works well because events are smaller since no value is sent to clients. Lazy near caching is still indiscriminate but we have plans to make it more selective, so that for example, only modified/removed events are sent for those keys that are stored in the client near cache, which would reduce traffic considerably (new jira to be created).
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years