[ https://jira.jboss.org/browse/ISPN-701?page=com.atlassian.jira.plugin.sys... ] Trustin Lee reassigned ISPN-701: -------------------------------- Assignee: Trustin Lee (was: Manik Surtani) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-701?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-701: ---------------------------------- Fix Version/s: 5.0.0.BETA2 (was: 5.0.0.BETA1) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-701?page=com.atlassian.jira.plugin.s... ] Galder Zamarreño updated ISPN-701: ---------------------------------- Fix Version/s: 5.0.0.CR1 (was: 5.0.0.BETA2) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-701?page=com.atlassian.jira.plugin.s... ] 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/... 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

[ https://issues.jboss.org/browse/ISPN-701?page=com.atlassian.jira.plugin.s... ] Trustin Lee commented on ISPN-701: ---------------------------------- Issue description has been rewritten to reflect the recent design discussion. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-701?page=com.atlassian.jira.plugin.s... ] Manik Surtani updated ISPN-701: ------------------------------- 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. 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

[ https://issues.jboss.org/browse/ISPN-701?page=com.atlassian.jira.plugin.s... ] Manik Surtani updated ISPN-701: ------------------------------- Assignee: Galder Zamarreño (was: Trustin Lee) Forum Reference: http://lists.jboss.org/pipermail/infinispan-dev/2010-October/006487.html (was: http://lists.jboss.org/pipermail/infinispan-dev/2010-October/006487.html) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/ISPN-701?page=com.atlassian.jira.plugin.s... ] Manik Surtani updated ISPN-701: ------------------------------- Fix Version/s: 6.0.0.FINAL (was: 5.2.0.FINAL) Forum Reference: http://lists.jboss.org/pipermail/infinispan-dev/2010-October/006487.html (was: http://lists.jboss.org/pipermail/infinispan-dev/2010-October/006487.html) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira