February 2020 - infinispan-issues

[JBoss JIRA] (ISPN-8238) Add spatial support to Ickle language

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-8238?page=com.atlassian.jira.plugin... ] Work on ISPN-8238 stopped by Tristan Tarrant. --------------------------------------------- > Add spatial support to Ickle language > ------------------------------------- > > Key: ISPN-8238 > URL: https://issues.redhat.com/browse/ISPN-8238 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying, Remote Querying > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8238) Add spatial support to Ickle language

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-8238?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-8238: ---------------------------------- Fix Version/s: (was: 10.1.0.Final) > Add spatial support to Ickle language > ------------------------------------- > > Key: ISPN-8238 > URL: https://issues.redhat.com/browse/ISPN-8238 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying, Remote Querying > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-7654) Ickle parser should have a different representation for each literal type instead of using string for everything

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-7654?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-7654: ---------------------------------- Fix Version/s: (was: 10.1.0.Final) > Ickle parser should have a different representation for each literal type instead of using string for everything > ---------------------------------------------------------------------------------------------------------------- > > Key: ISPN-7654 > URL: https://issues.redhat.com/browse/ISPN-7654 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying, Remote Querying > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > > All constant literals regardless of type are represented as string now and are later parsed into integers, booleans, etc, when the query is translated. We should do this at the beginning phase of parsing. See ConstantLiteralTree class. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8648) Support protobuf encoding as a storage format for embedded query

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-8648?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-8648: ---------------------------------- Fix Version/s: (was: 10.1.0.Final) > Support protobuf encoding as a storage format for embedded query > ---------------------------------------------------------------- > > Key: ISPN-8648 > URL: https://issues.redhat.com/browse/ISPN-8648 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > > This use case is alreay supported in remote mode and should also be supported in embedded mode. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9513) Transformers registered via SearchManagerImplementor.registerKeyTransformer should be propagated in the cluster

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-9513?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-9513: ---------------------------------- Fix Version/s: (was: 10.1.0.Final) > Transformers registered via SearchManagerImplementor.registerKeyTransformer should be propagated in the cluster > --------------------------------------------------------------------------------------------------------------- > > Key: ISPN-9513 > URL: https://issues.redhat.com/browse/ISPN-9513 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying > Affects Versions: 5.2.0.Final > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > > This can be achieved in a similar manner QueryKnownClasses is used to propagate indexed entities to other nodes. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8628) Simplify QueryEngine handling of Broadcast vs Fetch queries

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-8628?page=com.atlassian.jira.plugin... ] Work on ISPN-8628 stopped by Tristan Tarrant. --------------------------------------------- > Simplify QueryEngine handling of Broadcast vs Fetch queries > ----------------------------------------------------------- > > Key: ISPN-8628 > URL: https://issues.redhat.com/browse/ISPN-8628 > Project: Infinispan > Issue Type: Task > Reporter: Gustavo Fernandes > Assignee: Nistor Adrian > Priority: Minor > > [~anistor] commented > The existence of RemoteQueryDefinition and HsQueryRequest seems to be a symptom of misplaced responsibility. It all starts with QueryDefinition.initialize, which IMO should actually be placed inside QueryEngine, not QueryDefinition. Doing that refactoring will remove the need for RemoteQueryDefinition, which now exists just to differentiate between embedded and remote case, but that differentiation can be done inside the query engine itself. Also, HsQueryRequest is just a data holder that carries the return value of QueryEngine.createHsQuery. If QueryDefinition.initialize is moved to QueryEngine we would also not need this anymore. > I did not think about it in detail but maybe we would also need to make QueryDefinition mutable for QueryEngine and immutable for external parties. In that case we can extract QueryDefinition as an immutable interface (exposing getters only) and it's implementation class could have package local setters accessible to QueryEngine only. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-10493) Convert all MarshallerRegistration classes to SerializationContextInitializer

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-10493?page=com.atlassian.jira.plugi... ] Tristan Tarrant updated ISPN-10493: ----------------------------------- Fix Version/s: (was: 10.1.0.Final) > Convert all MarshallerRegistration classes to SerializationContextInitializer > ----------------------------------------------------------------------------- > > Key: ISPN-10493 > URL: https://issues.redhat.com/browse/ISPN-10493 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Querying > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8628) Simplify QueryEngine handling of Broadcast vs Fetch queries

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-8628?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-8628: ---------------------------------- Fix Version/s: (was: 10.1.0.Final) > Simplify QueryEngine handling of Broadcast vs Fetch queries > ----------------------------------------------------------- > > Key: ISPN-8628 > URL: https://issues.redhat.com/browse/ISPN-8628 > Project: Infinispan > Issue Type: Task > Reporter: Gustavo Fernandes > Assignee: Nistor Adrian > Priority: Minor > > [~anistor] commented > The existence of RemoteQueryDefinition and HsQueryRequest seems to be a symptom of misplaced responsibility. It all starts with QueryDefinition.initialize, which IMO should actually be placed inside QueryEngine, not QueryDefinition. Doing that refactoring will remove the need for RemoteQueryDefinition, which now exists just to differentiate between embedded and remote case, but that differentiation can be done inside the query engine itself. Also, HsQueryRequest is just a data holder that carries the return value of QueryEngine.createHsQuery. If QueryDefinition.initialize is moved to QueryEngine we would also not need this anymore. > I did not think about it in detail but maybe we would also need to make QueryDefinition mutable for QueryEngine and immutable for external parties. In that case we can extract QueryDefinition as an immutable interface (exposing getters only) and it's implementation class could have package local setters accessible to QueryEngine only. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6960) Add xor logic operator to query DSL

by Nistor Adrian (Jira)

[ https://issues.redhat.com/browse/ISPN-6960?page=com.atlassian.jira.plugin... ] Nistor Adrian closed ISPN-6960. ------------------------------- Resolution: Won't Do > Add xor logic operator to query DSL > ----------------------------------- > > Key: ISPN-6960 > URL: https://issues.redhat.com/browse/ISPN-6960 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying, Remote Querying > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8241) Refactor RocksDB clearThreshold

by Tristan Tarrant (Jira)

[ https://issues.redhat.com/browse/ISPN-8241?page=com.atlassian.jira.plugin... ] Work on ISPN-8241 stopped by Tristan Tarrant. --------------------------------------------- > Refactor RocksDB clearThreshold > ------------------------------- > > Key: ISPN-8241 > URL: https://issues.redhat.com/browse/ISPN-8241 > Project: Infinispan > Issue Type: Sub-task > Components: Loaders and Stores > Affects Versions: 9.1.0.Final > Reporter: Ryan Emerson > Assignee: Diego Lovison > Priority: Major > > Currently the RocksDB store utilises a "clearThreshold" to try to delete entries individually before deleting and re-initiating the database. We should deprecate this threshold and always delete/reinit the database. > Currently when deleting the database, we utilise Util.recursiveFileRemove which does not confirm that the file has actually been deleted. Instead, we should provide a nio based implementation instead, similar to the one stated [here|https://stackoverflow.com/questions/779519/delete-directories-recurs...]. This has the advantage that an IOException is thrown by java.nio.file.Files::delete -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2020