9:28 a.m.
Redesign TableManipulation in JDBC cache loader
-----------------------------------------------
Key: ISPN-701
URL: https://jira.jboss.org/browse/ISPN-701
Project: Infinispan
Issue Type: Task
Components: Loaders and Stores
Reporter: Trustin Lee
Assignee: Manik Surtani
Fix For: 5.0.0.BETA1, 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/...
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.
-
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
9:28 a.m.
New subject: [JBoss JIRA] Assigned: (ISPN-701) Redesign TableManipulation in JDBC cache loader
[
https://jira.jboss.org/browse/ISPN-701?page=com.atlassian.jira.plugin.sys...
]
Trustin Lee reassigned ISPN-701:
--------------------------------
Assignee: Trustin Lee (was: Manik Surtani)
Redesign TableManipulation in JDBC cache loader
-----------------------------------------------
Key: ISPN-701
URL: https://jira.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.BETA1, 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/...
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.
-
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
1:27 p.m.
New subject: [JBoss JIRA] Assigned: (ISPN-701) Redesign TableManipulation in JDBC cache loader
[
https://issues.jboss.org/browse/ISPN-701?page=com.atlassian.jira.plugin.s...
]
Mircea Markus reassigned ISPN-701:
----------------------------------
Assignee: Mircea Markus (was: Trustin Lee)
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: Mircea Markus
Fix For: 5.0.0.BETA1, 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/...
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
1:39 p.m.
New subject: [JBoss JIRA] Updated: (ISPN-701) Redesign TableManipulation in JDBC cache loader
[
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)
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: Mircea Markus
Fix For: 5.0.0.BETA2, 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/...
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
4:13 p.m.
New subject: [JBoss JIRA] Assigned: (ISPN-701) Redesign TableManipulation in JDBC cache loader
[
https://issues.jboss.org/browse/ISPN-701?page=com.atlassian.jira.plugin.s...
]
Manik Surtani reassigned ISPN-701:
----------------------------------
Assignee: Trustin Lee (was: Mircea Markus)
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.BETA2, 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/...
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
11:38 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-701) Redesign TableManipulation in JDBC cache loader
[
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)
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/...
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
1:18 p.m.
New subject: [JBoss JIRA] Commented: (ISPN-701) Redesign TableManipulation in JDBC cache loader
[
https://issues.jboss.org/browse/ISPN-701?page=com.atlassian.jira.plugin.s...
]
Manik Surtani commented on ISPN-701:
------------------------------------
@Trustin I presume you will re-jig this JIRA to suit the results of our design discussions
via email?
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/...
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
9:26 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-701) New JDBC CacheStore implementation w/ more flexible vendor-specific extension and binary key column support
[
https://issues.jboss.org/browse/ISPN-701?page=com.atlassian.jira.plugin.s...
]
Trustin Lee 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.
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.
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
9:26 a.m.
New subject: [JBoss JIRA] Updated: (ISPN-701) New JDBC CacheStore implementation w/ more flexible vendor-specific extension and binary key column support
[
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.
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
9:28 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-701) New JDBC CacheStore implementation w/ more flexible vendor-specific extension and binary key column support
[
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.
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
5:39 p.m.
New subject: [JBoss JIRA] Updated: (ISPN-701) New JDBC CacheStore implementation w/ more flexible vendor-specific extension and binary key column support
[
https://issues.jboss.org/browse/ISPN-701?page=com.atlassian.jira.plugin.s...
]
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
5:41 p.m.
New subject: [JBoss JIRA] Updated: (ISPN-701) New JDBC CacheStore implementation w/ more flexible vendor-specific extension and binary key column support
[
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.
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
6 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-701) New JDBC CacheStore implementation w/ more flexible vendor-specific extension and binary key column support
[
https://issues.jboss.org/browse/ISPN-701?page=com.atlassian.jira.plugin.s...
]
Trustin Lee commented on ISPN-701:
----------------------------------
Anothet idea - large value chunking:
http://infinispan.markmail.org/thread/xtubddwd6iye2vny
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
4:31 p.m.
New subject: [JBoss JIRA] Updated: (ISPN-701) New JDBC CacheStore implementation w/ more flexible vendor-specific extension and binary key column support
[
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)
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: Galder Zamarreño
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
4:37 p.m.
New subject: [JBoss JIRA] Updated: (ISPN-701) New JDBC CacheStore implementation w/ more flexible vendor-specific extension and binary key column support
[
https://issues.jboss.org/browse/ISPN-701?page=com.atlassian.jira.plugin.s...
]
Galder Zamarreño updated ISPN-701:
----------------------------------
Fix Version/s: 5.2.0.FINAL
(was: 5.1.0.BETA1)
(was: 5.1.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)
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: Galder Zamarreño
Labels: jdbc
Fix For: 5.2.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
4:45 p.m.
New subject: [JBoss JIRA] (ISPN-701) New JDBC CacheStore implementation w/ more flexible vendor-specific extension and binary key column support
[
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)
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: Galder Zamarreño
Labels: jdbc
Fix For: 6.0.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.
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
4:55 p.m.
New subject: [JBoss JIRA] (ISPN-701) New JDBC CacheStore implementation w/ more flexible vendor-specific extension and binary key column support
[
https://issues.jboss.org/browse/ISPN-701?page=com.atlassian.jira.plugin.s...
]
Tristan Tarrant reassigned ISPN-701:
------------------------------------
Assignee: Tristan Tarrant (was: Galder Zamarreño)
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: Tristan Tarrant
Labels: jdbc
Fix For: 6.0.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.
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
4469
days inactive
4943
days old
infinispan-issues@lists.jboss.org
16 comments
5 participants
participants (5)
-
Galder Zamarreño (JIRA) -
Manik Surtani (JIRA)
-
Mircea Markus (JIRA)
-
Tristan Tarrant (JIRA)
-
Trustin Lee (JIRA)