[infinispan-issues] [JBoss JIRA] Updated: (ISPN-701) Redesign TableManipulation in JDBC cache loader

[Galder Zamarreño (JIRA)]

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

Galder Zamarreño updated ISPN-701:
----------------------------------

    Fix Version/s: 5.0.0.CR1
                       (was: 5.0.0.BETA2)


> Redesign TableManipulation in JDBC cache loader
> -----------------------------------------------
>
>                 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.0.0.CR1, 5.0.0.FINAL
>
>
> 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.

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