[JBoss JIRA] (ISPN-11629) Initialize DataConversion storage media type only once
by Gustavo Fernandes (Jira)
[ https://issues.redhat.com/browse/ISPN-11629?page=com.atlassian.jira.plugi... ]
Gustavo Fernandes updated ISPN-11629:
-------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Initialize DataConversion storage media type only once
> ------------------------------------------------------
>
> Key: ISPN-11629
> URL: https://issues.redhat.com/browse/ISPN-11629
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 11.0.0.Dev03
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.CR1
>
>
> {{DataConversion}} constructors have a {{storageMediaType}} parameter, but then the storage media type is overridden in {{injectDependencies()}}, except for the static instances defined as constants in {{DataConversion}}.
> {{InternalCacheFactory}} can also be simplified to only use the {{DataConversion}} s to create the {{EncoderCache}}, without passing them to the wrapped cache(s).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (ISPN-11855) Internal caches should ignore wildcard configurations
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11855?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11855:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/8359
> Internal caches should ignore wildcard configurations
> -----------------------------------------------------
>
> Key: ISPN-11855
> URL: https://issues.redhat.com/browse/ISPN-11855
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 11.0.0.Dev05, 10.1.8.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.CR1, 10.1.9.Final
>
>
> {{InternalCacheRegistryImpl.registerInternalCache}} throws a {{CacheConfigurationException}} if a wildcard configuration matches the internal cache name.
> It should ignore wildcard configurations instead, and a user should be able to replicate the pre-ISPN-11367 behaviour with a {{*}} wildcard:
> {code:xml}
> <cache-container>
> <local-cache-configuration name="*">
> </local-cache-configuration>
> </cache-container>
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (ISPN-11855) Internal caches should ignore wildcard configurations
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-11855?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-11855:
--------------------------------
Status: Open (was: New)
> Internal caches should ignore wildcard configurations
> -----------------------------------------------------
>
> Key: ISPN-11855
> URL: https://issues.redhat.com/browse/ISPN-11855
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 11.0.0.Dev05, 10.1.8.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.0.CR1, 10.1.9.Final
>
>
> {{InternalCacheRegistryImpl.registerInternalCache}} throws a {{CacheConfigurationException}} if a wildcard configuration matches the internal cache name.
> It should ignore wildcard configurations instead, and a user should be able to replicate the pre-ISPN-11367 behaviour with a {{*}} wildcard:
> {code:xml}
> <cache-container>
> <local-cache-configuration name="*">
> </local-cache-configuration>
> </cache-container>
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (ISPN-11875) JDBC Loader
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11875?page=com.atlassian.jira.plugi... ]
Tristan Tarrant moved JDGPL-305 to ISPN-11875:
----------------------------------------------
Project: Infinispan (was: JDG planning)
Key: ISPN-11875 (was: JDGPL-305)
Issue Type: Feature Request (was: Requirement)
Workflow: GIT Pull Request with Triage workflow (was: RHMAP Workflow)
Component/s: Loaders and Stores
(was: Persistence)
> JDBC Loader
> -----------
>
> Key: ISPN-11875
> URL: https://issues.redhat.com/browse/ISPN-11875
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Reporter: Tristan Tarrant
> Assignee: Ryan Emerson
> Priority: Optional
>
> As a application developer or data grid administrator, I want to preload a cache from a relational database accessed by JDBC - via configuration without writing boilerplate code.
>
> *Solution*
> A read-only cache loader will be implemented to allow users achieve that goal by following the steps.
> The cache loader is configured per cache.
> *Step 1. Configuration* - The required set of parameters are:
> _Data source configuration_:
> _SQL query to retrieve_ I.e “select isin, title as t, description from books”
>
> A query that will retrieve all the keys and values to put into the cache, with the following structure and conventions:
> * First column, will map to a key of type String
> * Rest of columns, will map to a value of type: String, Byte[] or a complext Protobuf object
> Mapping of every row to a cache key/value will work as follows:
>
> * Simple key and values: If the query returns only 2 columns, and the second one is either String or Byte[], the value will be the content of the second column. No protobuf schema is needed.
> Example, 'select code, country from country_list"
> * Simple key and complex value. If query returns 2+ columns, a Protobuf schema will be automatically generated and used to encode all the columns' values.
> Example, "select code, country, region, total_sales from sales_results"
>
> *Step 2. Execution on cache initialization*
> The cache loader will:
> # Flush the cache
> # Run the SQL query
> # Generate Protobuf schema, if needed. Register it in the Protobuf schemas cache.
> # Transform every row of the resultset into a key and a simple value, or an object composed of simple types.
> # Put(key,value) into the cache
> # The cache will not available during the initialization process
> *Optional, Step 3. Additional refresh*
> To refresh the data after the startup, several options will exist:
> # server restart
> # Invoke a JMX operation
> # Use CLI to invoke same operation
> # Use console to invoke same operation
> *Other usability considerations.*
> Generated Protobuf schemas will be available for usage by remote clients by:
> - Download from console, for administration.
> - Printed out in console during generation, for copy & paste, for regular development.
> - Access the protobuf cache directly, for programmatic usage.
> - Console will be updated with this capability
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (ISPN-11875) JDBC Loader
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11875?page=com.atlassian.jira.plugi... ]
Tristan Tarrant reassigned ISPN-11875:
--------------------------------------
Assignee: (was: Ryan Emerson)
> JDBC Loader
> -----------
>
> Key: ISPN-11875
> URL: https://issues.redhat.com/browse/ISPN-11875
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Reporter: Tristan Tarrant
> Priority: Optional
>
> As a application developer or data grid administrator, I want to preload a cache from a relational database accessed by JDBC - via configuration without writing boilerplate code.
>
> *Solution*
> A read-only cache loader will be implemented to allow users achieve that goal by following the steps.
> The cache loader is configured per cache.
> *Step 1. Configuration* - The required set of parameters are:
> _Data source configuration_:
> _SQL query to retrieve_ I.e “select isin, title as t, description from books”
>
> A query that will retrieve all the keys and values to put into the cache, with the following structure and conventions:
> * First column, will map to a key of type String
> * Rest of columns, will map to a value of type: String, Byte[] or a complext Protobuf object
> Mapping of every row to a cache key/value will work as follows:
>
> * Simple key and values: If the query returns only 2 columns, and the second one is either String or Byte[], the value will be the content of the second column. No protobuf schema is needed.
> Example, 'select code, country from country_list"
> * Simple key and complex value. If query returns 2+ columns, a Protobuf schema will be automatically generated and used to encode all the columns' values.
> Example, "select code, country, region, total_sales from sales_results"
>
> *Step 2. Execution on cache initialization*
> The cache loader will:
> # Flush the cache
> # Run the SQL query
> # Generate Protobuf schema, if needed. Register it in the Protobuf schemas cache.
> # Transform every row of the resultset into a key and a simple value, or an object composed of simple types.
> # Put(key,value) into the cache
> # The cache will not available during the initialization process
> *Optional, Step 3. Additional refresh*
> To refresh the data after the startup, several options will exist:
> # server restart
> # Invoke a JMX operation
> # Use CLI to invoke same operation
> # Use console to invoke same operation
> *Other usability considerations.*
> Generated Protobuf schemas will be available for usage by remote clients by:
> - Download from console, for administration.
> - Printed out in console during generation, for copy & paste, for regular development.
> - Access the protobuf cache directly, for programmatic usage.
> - Console will be updated with this capability
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months
[JBoss JIRA] (ISPN-11875) JDBC Loader
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11875?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11875:
-----------------------------------
Priority: Major (was: Optional)
> JDBC Loader
> -----------
>
> Key: ISPN-11875
> URL: https://issues.redhat.com/browse/ISPN-11875
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Reporter: Tristan Tarrant
> Priority: Major
>
> As a application developer or data grid administrator, I want to preload a cache from a relational database accessed by JDBC - via configuration without writing boilerplate code.
>
> *Solution*
> A read-only cache loader will be implemented to allow users achieve that goal by following the steps.
> The cache loader is configured per cache.
> *Step 1. Configuration* - The required set of parameters are:
> _Data source configuration_:
> _SQL query to retrieve_ I.e “select isin, title as t, description from books”
>
> A query that will retrieve all the keys and values to put into the cache, with the following structure and conventions:
> * First column, will map to a key of type String
> * Rest of columns, will map to a value of type: String, Byte[] or a complext Protobuf object
> Mapping of every row to a cache key/value will work as follows:
>
> * Simple key and values: If the query returns only 2 columns, and the second one is either String or Byte[], the value will be the content of the second column. No protobuf schema is needed.
> Example, 'select code, country from country_list"
> * Simple key and complex value. If query returns 2+ columns, a Protobuf schema will be automatically generated and used to encode all the columns' values.
> Example, "select code, country, region, total_sales from sales_results"
>
> *Step 2. Execution on cache initialization*
> The cache loader will:
> # Flush the cache
> # Run the SQL query
> # Generate Protobuf schema, if needed. Register it in the Protobuf schemas cache.
> # Transform every row of the resultset into a key and a simple value, or an object composed of simple types.
> # Put(key,value) into the cache
> # The cache will not available during the initialization process
> *Optional, Step 3. Additional refresh*
> To refresh the data after the startup, several options will exist:
> # server restart
> # Invoke a JMX operation
> # Use CLI to invoke same operation
> # Use console to invoke same operation
> *Other usability considerations.*
> Generated Protobuf schemas will be available for usage by remote clients by:
> - Download from console, for administration.
> - Printed out in console during generation, for copy & paste, for regular development.
> - Access the protobuf cache directly, for programmatic usage.
> - Console will be updated with this capability
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 7 months