[infinispan-issues] [JBoss JIRA] Updated: (ISPN-701) New JDBC CacheStore implementation w/ more flexible vendor-specific extension and binary key column support

[Manik Surtani (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Manik Surtani updated ISPN-701:
-------------------------------

         Labels: jdbc  (was: )
    Description: 
The current JDBC {{CacheStore}} implementation has the following shortcomings:

* poor support for vendor specific queries (e.g. MySQL's replace into)
* complex configuration is required to support the key types that cannot be converted to a String easily.

To address this issue:

* Introduce a single unified JDBC {{CacheStore}} implementation.
* Support an arbitrary key type as long as it can be serialized via {{Marshaller}}.
* Support both text and binary key.
* Encode the binary key into a text key using an efficient text encoding if the target database doesn't support binary key column.
* Provide much more flexibility in supporting vendor specific extensions. Let the user extend our {{CacheStore}} implementation and override the DB access (no more TableManipulation).

Once implemented, the existing JDBC {{CacheStore}} could be deprecated.

Configuring this would be, for example, {{GenericJdbcCacheStore}} which would have no vendor-specific optimisations, and {{MySqlJdbcCacheStore}} (subclasses GenericJdbcCacheStore}}) which would contain MySQL specific optimisations, etc.

  was:
The current JDBC {{CacheStore}} implementation has the following shortcomings:

* poor support for vendor specific queries (e.g. MySQL's replace into)
* complex configuration is required to support the key types that cannot be converted to a String easily.

To address this issue:

* Introduce a single unified JDBC {{CacheStore}} implementation.
* Support an arbitrary key type as long as it can be serialized via {{Marshaller}}.
* Support both text and binary key.
* Encode the binary key into a text key using an efficient text encoding if the target database doesn't support binary key column.
* Provide much more flexibility in supporting vendor specific extensions. Let the user extend our {{CacheStore}} implementation and override the DB access (no more TableManipulation).

Once implemented, the existing JDBC {{CacheStore}} could be deprecated.

     Complexity: Medium


> New JDBC CacheStore implementation w/ more flexible vendor-specific extension and binary key column support
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: ISPN-701
>                 URL: https://issues.jboss.org/browse/ISPN-701
>             Project: Infinispan
>          Issue Type: Task
>          Components: Loaders and Stores
>            Reporter: Trustin Lee
>            Assignee: Trustin Lee
>              Labels: jdbc
>             Fix For: 5.1.0.BETA1, 5.1.0.Final
>
>
> The current JDBC {{CacheStore}} implementation has the following shortcomings:
> * poor support for vendor specific queries (e.g. MySQL's replace into)
> * complex configuration is required to support the key types that cannot be converted to a String easily.
> To address this issue:
> * Introduce a single unified JDBC {{CacheStore}} implementation.
> * Support an arbitrary key type as long as it can be serialized via {{Marshaller}}.
> * Support both text and binary key.
> * Encode the binary key into a text key using an efficient text encoding if the target database doesn't support binary key column.
> * Provide much more flexibility in supporting vendor specific extensions. Let the user extend our {{CacheStore}} implementation and override the DB access (no more TableManipulation).
> Once implemented, the existing JDBC {{CacheStore}} could be deprecated.
> Configuring this would be, for example, {{GenericJdbcCacheStore}} which would have no vendor-specific optimisations, and {{MySqlJdbcCacheStore}} (subclasses GenericJdbcCacheStore}}) which would contain MySQL specific optimisations, etc.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira