[JBoss JIRA] (ISPN-12218) Indexed caches with non-indexed entities query inconsistency
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-12218?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes edited comment on ISPN-12218 at 8/13/20 3:50 AM:
-------------------------------------------------------------------
[~anistor] I am not sure what to do here. This happens in 11.x (haven't tested on 12). I attached a reproducer for 11.x. It seems to me that it should throw an error rather them trying to the query when the user configures {{addIndexedEntity("Entity")}} with a non-indexed entity
was (Author: gustavonalle):
[~anistor] I am not sure what to do here. This happens in 11.x (haven't tested on 12), with indexed caches with unindexed entities, "FROM Entity" does a lucene query while "FROM Entity WHERE ..." does a non-indexed query, and the results are inconsistent. I attached a reproducer for 11.x
> Indexed caches with non-indexed entities query inconsistency
> ------------------------------------------------------------
>
> Key: ISPN-12218
> URL: https://issues.redhat.com/browse/ISPN-12218
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Remote Querying
> Affects Versions: 11.0.3.Final
> Reporter: Gustavo Fernandes
> Priority: Major
> Attachments: IndexedCacheNonIndexedQueryTest.java
>
>
> When a cache is indexed, but the protobuf entitiy is not:
> "FROM Entity" returns zero results
> "FROM Entity WHERE <predicate>" return results
> It appears in the first case the query goes to the index (that will be empty), but not in the second where it does a non-indexed query
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ISPN-12218) Indexed caches with non-indexed entities query inconsistency
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-12218?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-12218:
-------------------------------------
Attachment: IndexedCacheNonIndexedQueryTest.java
> Indexed caches with non-indexed entities query inconsistency
> ------------------------------------------------------------
>
> Key: ISPN-12218
> URL: https://issues.redhat.com/browse/ISPN-12218
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Remote Querying
> Affects Versions: 11.0.3.Final
> Reporter: Gustavo Fernandes
> Priority: Major
> Attachments: IndexedCacheNonIndexedQueryTest.java
>
>
> When a cache is indexed, but the protobuf entitiy is not:
> "FROM Entity" returns zero results
> "FROM Entity WHERE <predicate>" return results
> It appears in the first case the query goes to the index (that will be empty), but not in the second where it does a non-indexed query
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ISPN-12218) Indexed caches with non-indexed entities query inconsistency
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-12218?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes commented on ISPN-12218:
------------------------------------------
[~anistor] I am not sure what to do here. This happens in 11.x (haven't tested on 12), with indexed caches with unindexed entities, "FROM Entity" does a lucene query while "FROM Entity WHERE ..." does a non-indexed query, and the results are inconsistent. I attached a reproducer for 11.x
> Indexed caches with non-indexed entities query inconsistency
> ------------------------------------------------------------
>
> Key: ISPN-12218
> URL: https://issues.redhat.com/browse/ISPN-12218
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying, Remote Querying
> Affects Versions: 11.0.3.Final
> Reporter: Gustavo Fernandes
> Priority: Major
> Attachments: IndexedCacheNonIndexedQueryTest.java
>
>
> When a cache is indexed, but the protobuf entitiy is not:
> "FROM Entity" returns zero results
> "FROM Entity WHERE <predicate>" return results
> It appears in the first case the query goes to the index (that will be empty), but not in the second where it does a non-indexed query
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ISPN-12170) Query - Stop encoding the segment ID in document IDs
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-12170?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes resolved ISPN-12170.
--------------------------------------
Resolution: Out of Date
> Query - Stop encoding the segment ID in document IDs
> ----------------------------------------------------
>
> Key: ISPN-12170
> URL: https://issues.redhat.com/browse/ISPN-12170
> Project: Infinispan
> Issue Type: Task
> Components: Embedded Querying, Remote Querying
> Affects Versions: 12.0.0.Dev01
> Reporter: Yoann Rodière
> Assignee: Gustavo Fernandes
> Priority: Major
> Fix For: 12.0.0.Dev02
>
>
> We're currently relying on a hack to determine routing keys for indexed documents in Infinispan Query. That is, we concatenate the ID with the segment ID, and use a routing key bridge to extract the segment ID then use it as a routing key.
>
> A nasty side-effect is that we include the segment ID in the ID of indexed documents in the index.
>
> With Hibernate Search 6.0.0.Beta9, this won't be necessary anymore: we'll be able to pass the segment ID (routing key) to Hibernate Search directly. This means we'll be able to remove the hack and to use cleaner document IDs.
>
> This removal means documents will have a different ID, and thus any existing index will have to be rebuilt. Thus this should be done ASAP.
>
> See the implementation of RoutingKeyBridge in Infinispan, and see [https://hibernate.atlassian.net/browse/HSEARCH-3891]
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ISPN-12186) Upgrade to Hibernate Search 6.0.0.Beta9
by Nistor Adrian (Jira)
[ https://issues.redhat.com/browse/ISPN-12186?page=com.atlassian.jira.plugi... ]
Nistor Adrian updated ISPN-12186:
---------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Upgrade to Hibernate Search 6.0.0.Beta9
> ---------------------------------------
>
> Key: ISPN-12186
> URL: https://issues.redhat.com/browse/ISPN-12186
> Project: Infinispan
> Issue Type: Task
> Components: Embedded Querying, Remote Querying
> Reporter: Yoann Rodière
> Assignee: Gustavo Fernandes
> Priority: Major
> Fix For: 12.0.0.Dev02
>
>
> TODO:
> * Upgrade the Hibernate Search dependency (obviously); be warned the Lucene dependency is now 8.6.0
> * Handle [deprecations and breaking changes|https://in.relation.to/2020/08/03/hibernate-search-6-0-0-Beta9/#breaking_changes]
> * Simplify the configuration properties generated by Infinispan and passed to Hibernate Search; see [here|https://in.relation.to/2020/08/03/hibernate-search-6-0-0-Beta9/#simpler-configuration-scheme].
> * Simplify the generation of IDs: {{org.hibernate.search.mapper.pojo.work.spi.PojoIndexer}} now allows passing the routing key explicitly (in our case, {{String.valueOf(segmentId)}}), so our custom implementation of {{RoutingKeyBridge}} (which relies on a hack) is no longer necessary.
> * As a result of the previous item, we can also get rid of the hack that concatenates the segment ID to the document ID; see ISPN-12170.
>
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ISPN-12169) Avoid to wrap the SearchMapping
by Fabio Massimo Ercoli (Jira)
[ https://issues.redhat.com/browse/ISPN-12169?page=com.atlassian.jira.plugi... ]
Fabio Massimo Ercoli commented on ISPN-12169:
---------------------------------------------
Pull request sent --> [https://github.com/infinispan/infinispan/pull/8622]
> Avoid to wrap the SearchMapping
> -------------------------------
>
> Key: ISPN-12169
> URL: https://issues.redhat.com/browse/ISPN-12169
> Project: Infinispan
> Issue Type: Task
> Components: Embedded Querying, Remote Querying
> Affects Versions: 12.0.0.Dev01
> Reporter: Fabio Massimo Ercoli
> Assignee: Fabio Massimo Ercoli
> Priority: Major
> Fix For: 12.0.0.Final
>
>
> Thanks to the fact that now the {{SerializationContext}} must contain all the indexed entities at cache starting time we can avoid to wrap the {{SearchMapping}} instance with a {{SearchMappingHolder}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months
[JBoss JIRA] (ISPN-12222) Infinispan Backup Operator Integration
by Ryan Emerson (Jira)
[ https://issues.redhat.com/browse/ISPN-12222?page=com.atlassian.jira.plugi... ]
Ryan Emerson updated ISPN-12222:
--------------------------------
Description:
In kubernetes environments the operator can be used to automate the steps required by a user to perform a backup of container content.
Typically an Infinispan pod will have a minimal volume size in order to prevent excessive resource allocation, say 1GB. However, if a cluster is large then it's very likely that it's in-memory content will exceed this amount. Therefore, during a cluster backup it's necessary to mount a volume with sufficient capacity to accomodate the created backup file. To automate this process we should create a backup CRD.
h3. Workflow
The operator provisions an additional pod with a mounted volume for storing the final backup. This pod joins the Infinispan cluster with {{zero-capacity-node=true}} so that no state-transfer is performed when joining. The operator then initiates the backup procedure on this node, via this node's REST endpoint, using the path of the mounted volume as the backups final destination. On completion, the pod of the zero-capacity-node is terminated.
h4. Restore
The same workflow can be used for restoring a backup from an existing volume.
h3. CR Parameters:
* Backup path
* Resources to include
* Existing volume to mount
* Create volume with x capacity, x could be automatically determined by inspecting the container content
* Shutdown cluster on completion?
> Infinispan Backup Operator Integration
> --------------------------------------
>
> Key: ISPN-12222
> URL: https://issues.redhat.com/browse/ISPN-12222
> Project: Infinispan
> Issue Type: Enhancement
> Components: Operator
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
>
> In kubernetes environments the operator can be used to automate the steps required by a user to perform a backup of container content.
> Typically an Infinispan pod will have a minimal volume size in order to prevent excessive resource allocation, say 1GB. However, if a cluster is large then it's very likely that it's in-memory content will exceed this amount. Therefore, during a cluster backup it's necessary to mount a volume with sufficient capacity to accomodate the created backup file. To automate this process we should create a backup CRD.
> h3. Workflow
> The operator provisions an additional pod with a mounted volume for storing the final backup. This pod joins the Infinispan cluster with {{zero-capacity-node=true}} so that no state-transfer is performed when joining. The operator then initiates the backup procedure on this node, via this node's REST endpoint, using the path of the mounted volume as the backups final destination. On completion, the pod of the zero-capacity-node is terminated.
> h4. Restore
> The same workflow can be used for restoring a backup from an existing volume.
> h3. CR Parameters:
> * Backup path
> * Resources to include
> * Existing volume to mount
> * Create volume with x capacity, x could be automatically determined by inspecting the container content
> * Shutdown cluster on completion?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 7 months