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

[Trustin Lee (JIRA)]

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

Trustin Lee updated ISPN-701:
-----------------------------

          Summary: New JDBC CacheStore implementation w/ more flexible vendor-specific extension and binary key column support  (was: Redesign TableManipulation in JDBC cache loader)
    Fix Version/s: 5.1.0.BETA1
                   5.1.0.Final
                       (was: 5.0.0.FINAL)
                       (was: 5.0.0.CR1)
      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.

  was:
There are two on-going issues related with TableManipulation at the moment: ISPN-686 and ISPN-698.  They both are related with vendor specific behavior, and the current implementation uses switch-cases to deal with the differences between vendors.  Could we instead use inheritance to make the code look cleaner and easier to maintain?  Hibernate does so:

    http://viewvc.jboss.org/cgi-bin/viewvc.cgi/hibernate/core/trunk/core/src/main/java/org/hibernate/dialect/

Also, the properties like custom types, names, prefixes, fetch/batch sizes could be moved to AbstractJdbcCacheStoreConfig (or its subclass because we have mixed JDBC store) instead of exposing TableManipulation directly to a user.

Since Hibernate already provides very well defined dialect metadata model, we could simply tap into it.  However, we should wrap it with a simple wrapper class so that a user can configure the JDBC store without the knowledge of Hibernate.

This is a backward incompatible change - will be done in 5.0, and TableManipulation and its related methods should be deprecated in 4.2.



> 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
>             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.

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