February 2016 - infinispan-issues

[JBoss JIRA] (ISPN-6178) Add ability to define indexable classes via config

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6178?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6178: -------------------------------- Description: Queryable classes are currently auto-detected on the fly by the QueryInterceptor on each write operation. The set of discovered classes is replicated by means of ClusterRegistry. This approach creates a lot of technical complexity and the implementation has a number of flaws; some have been fixed after several iterations but the solution is still brittle and can lead to locking issues. It also forces Hibernate Search to reconfigure the factory which is rather messy. In stead of continuing to patch and 'improve' this we should consider pre-declaring the indexable classes in the cache configuration (indexing configuration actually). Given the impact of this change to existing codebase I would propose an approach that allows an easy transition: 1. Introduction of a new config in indexing configuration to be able to specify the classes. 2. If cache is indexed but no indexable classes were defined fallback to on-demand auto-detection as it worked in 8.1. 3. If cache is indexed and classes were specified use them and do not perform on-demand auto-detection anymore. This is how it should work in 8.2. Auto-detection should also be documented as deprecated in 8.2 and should be removed completely in 9.0. In 9.0 marking a cache as indexed but not specifying which exact classes should result in an error at config time validation. was: Queryable classes are currently auto-detected on the fly by the QueryInterceptor on each write operation. The set of discovered classes is replciated by means of ClusterRegistry. This approach creates a lot of technical complexity and the implementation has a number of flaws; some have been fixed after several iterations but the solution is still brittle and can lead to locking issues. It also forces Hibernate Search to reconfigure the factory which is rather messy. In stead of continuing to patch and 'improve' this we should consider pre-declaring the indexable classes in the cache configuration (indexing configuration actually). Given the impact of this change to existing codebase I would propose an approach that allows an easy transition: 1. Introduction of a new config in indexing configuration to be able to specify the classes. 2. If cache is indexed but no indexable classes were defined fallback to on-demand auto-detection as it worked in 8.1. 3. If cache is indexed and classes were specified use them and do not perform on-demand auto-detection anymore. This is how it should work in 8.2. Auto-detection should also be documented as deprecated in 8.2 and should be removed completely in 9.0. In 9.0 marking a cache as indexed but not specifying which exact classes should result in an error at config time validation. > Add ability to define indexable classes via config > -------------------------------------------------- > > Key: ISPN-6178 > URL: https://issues.jboss.org/browse/ISPN-6178 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.2.0.Final > > > Queryable classes are currently auto-detected on the fly by the QueryInterceptor on each write operation. The set of discovered classes is replicated by means of ClusterRegistry. > This approach creates a lot of technical complexity and the implementation has a number of flaws; some have been fixed after several iterations but the solution is still brittle and can lead to locking issues. It also forces Hibernate Search to reconfigure the factory which is rather messy. In stead of continuing to patch and 'improve' this we should consider pre-declaring the indexable classes in the cache configuration (indexing configuration actually). > Given the impact of this change to existing codebase I would propose an approach that allows an easy transition: > 1. Introduction of a new config in indexing configuration to be able to specify the classes. > 2. If cache is indexed but no indexable classes were defined fallback to on-demand auto-detection as it worked in 8.1. > 3. If cache is indexed and classes were specified use them and do not perform on-demand auto-detection anymore. > This is how it should work in 8.2. Auto-detection should also be documented as deprecated in 8.2 and should be removed completely in 9.0. In 9.0 marking a cache as indexed but not specifying which exact classes should result in an error at config time validation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6178) Add ability to define indexable classes via config

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-6178: ----------------------------------- Summary: Add ability to define indexable classes via config Key: ISPN-6178 URL: https://issues.jboss.org/browse/ISPN-6178 Project: Infinispan Issue Type: Feature Request Components: Embedded Querying Reporter: Adrian Nistor Queryable classes are currently auto-detected on the fly by the QueryInterceptor on each write operation. The set of discovered classes is replciated by means of ClusterRegistry. This approach creates a lot of technical complexity and the implementation has a number of flaws; some have been fixed after several iterations but the solution is still brittle and can lead to locking issues. It also forces Hibernate Search to reconfigure the factory which is rather messy. In stead of continuing to patch and 'improve' this we should consider pre-declaring the indexable classes in the cache configuration (indexing configuration actually). Given the impact of this change to existing codebase I would propose an approach that allows an easy transition: 1. Introduction of a new config in indexing configuration to be able to specify the classes. 2. If cache is indexed but no indexable classes were defined fallback to on-demand auto-detection as it worked in 8.1. 3. If cache is indexed and classes were specified use them and do not perform on-demand auto-detection anymore. This is how it should work in 8.2. Auto-detection should also be documented as deprecated in 8.2 and should be removed completely in 9.0. In 9.0 marking a cache as indexed but not specifying which exact classes should result in an error at config time validation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6178) Add ability to define indexable classes via config

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6178?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6178: -------------------------------- Status: Open (was: New) > Add ability to define indexable classes via config > -------------------------------------------------- > > Key: ISPN-6178 > URL: https://issues.jboss.org/browse/ISPN-6178 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying > Reporter: Adrian Nistor > > Queryable classes are currently auto-detected on the fly by the QueryInterceptor on each write operation. The set of discovered classes is replciated by means of ClusterRegistry. > This approach creates a lot of technical complexity and the implementation has a number of flaws; some have been fixed after several iterations but the solution is still brittle and can lead to locking issues. It also forces Hibernate Search to reconfigure the factory which is rather messy. In stead of continuing to patch and 'improve' this we should consider pre-declaring the indexable classes in the cache configuration (indexing configuration actually). > Given the impact of this change to existing codebase I would propose an approach that allows an easy transition: > 1. Introduction of a new config in indexing configuration to be able to specify the classes. > 2. If cache is indexed but no indexable classes were defined fallback to on-demand auto-detection as it worked in 8.1. > 3. If cache is indexed and classes were specified use them and do not perform on-demand auto-detection anymore. > This is how it should work in 8.2. Auto-detection should also be documented as deprecated in 8.2 and should be removed completely in 9.0. In 9.0 marking a cache as indexed but not specifying which exact classes should result in an error at config time validation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6178) Add ability to define indexable classes via config

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6178?page=com.atlassian.jira.plugin.... ] Adrian Nistor reassigned ISPN-6178: ----------------------------------- Assignee: Adrian Nistor > Add ability to define indexable classes via config > -------------------------------------------------- > > Key: ISPN-6178 > URL: https://issues.jboss.org/browse/ISPN-6178 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > > Queryable classes are currently auto-detected on the fly by the QueryInterceptor on each write operation. The set of discovered classes is replciated by means of ClusterRegistry. > This approach creates a lot of technical complexity and the implementation has a number of flaws; some have been fixed after several iterations but the solution is still brittle and can lead to locking issues. It also forces Hibernate Search to reconfigure the factory which is rather messy. In stead of continuing to patch and 'improve' this we should consider pre-declaring the indexable classes in the cache configuration (indexing configuration actually). > Given the impact of this change to existing codebase I would propose an approach that allows an easy transition: > 1. Introduction of a new config in indexing configuration to be able to specify the classes. > 2. If cache is indexed but no indexable classes were defined fallback to on-demand auto-detection as it worked in 8.1. > 3. If cache is indexed and classes were specified use them and do not perform on-demand auto-detection anymore. > This is how it should work in 8.2. Auto-detection should also be documented as deprecated in 8.2 and should be removed completely in 9.0. In 9.0 marking a cache as indexed but not specifying which exact classes should result in an error at config time validation. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6177) Add ability to pre-register protobuf schema definitions via config

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6177?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6177: -------------------------------- Summary: Add ability to pre-register protobuf schema definitions via config (was: Add ability to pre-register protuf schema definitions via config) > Add ability to pre-register protobuf schema definitions via config > ------------------------------------------------------------------ > > Key: ISPN-6177 > URL: https://issues.jboss.org/browse/ISPN-6177 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Priority: Minor > > The global config should name some *.proto files (from disk or CP resources) to be registered with the ProtobufMetadataManager on startup. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6177) Add ability to pre-register protuf schema definitions via config

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6177?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6177: -------------------------------- Status: Open (was: New) > Add ability to pre-register protuf schema definitions via config > ---------------------------------------------------------------- > > Key: ISPN-6177 > URL: https://issues.jboss.org/browse/ISPN-6177 > Project: Infinispan > Issue Type: Feature Request > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Priority: Minor > > The global config should name some *.proto files (from disk or CP resources) to be registered with the ProtobufMetadataManager on startup. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6177) Add ability to pre-register protuf schema definitions via config

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-6177: ----------------------------------- Summary: Add ability to pre-register protuf schema definitions via config Key: ISPN-6177 URL: https://issues.jboss.org/browse/ISPN-6177 Project: Infinispan Issue Type: Feature Request Components: Remote Querying Reporter: Adrian Nistor Assignee: Adrian Nistor Priority: Minor The global config should name some *.proto files (from disk or CP resources) to be registered with the ProtobufMetadataManager on startup. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6060) Add aggregation and grouping to continuous query

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6060?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6060: -------------------------------- Description: To be defined. This only makes sense for the materialized view approach of continuous query, which is not implemented yet. was:To be defined. > Add aggregation and grouping to continuous query > ------------------------------------------------ > > Key: ISPN-6060 > URL: https://issues.jboss.org/browse/ISPN-6060 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying, Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.0.0.Final > > > To be defined. > This only makes sense for the materialized view approach of continuous query, which is not implemented yet. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6160) Remove deprecated methods in ProtobufMetadataManager

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6160?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6160: -------------------------------- Status: Open (was: New) > Remove deprecated methods in ProtobufMetadataManager > ---------------------------------------------------- > > Key: ISPN-6160 > URL: https://issues.jboss.org/browse/ISPN-6160 > Project: Infinispan > Issue Type: Enhancement > Components: JMX, reporting and management, Remote Querying > Reporter: Tristan Tarrant > Assignee: Adrian Nistor > Fix For: 9.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6159) Remove ClientEvents.addContinuousQueryListener

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6159?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6159: -------------------------------- Status: Open (was: New) > Remove ClientEvents.addContinuousQueryListener > ---------------------------------------------- > > Key: ISPN-6159 > URL: https://issues.jboss.org/browse/ISPN-6159 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Querying > Reporter: Tristan Tarrant > Assignee: Adrian Nistor > Fix For: 9.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

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 2016