[JBoss JIRA] (ISPN-6743) Upsert does not work for MySQL
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-6743?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-6743:
-------------------------------
Status: Open (was: New)
> Upsert does not work for MySQL
> ------------------------------
>
> Key: ISPN-6743
> URL: https://issues.jboss.org/browse/ISPN-6743
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 9.0.0.Alpha2
> Reporter: Krzysztof Sobolewski
> Assignee: Ryan Emerson
>
> ISPN-20, merged recently (thanks!), added "upsert" support for JDBC cache stores. The "upsert" SQL statement is database-type-dependent and the one for MySQL has a different "API" than the one for other database types - whereas all the others use the same number and order of placeholders as the equvalent INSERT statement, so that the same method can be used to update the INSERT, UPDATE and "upsert" statement, the MySQL one adds additional placeholders and the aforementioned method is no longer sufficient.
> The exception is:
> java.sql.SQLException: No value specified for parameter 4
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (ISPN-6743) Upsert does not work for MySQL
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-6743?page=com.atlassian.jira.plugin.... ]
Ryan Emerson reassigned ISPN-6743:
----------------------------------
Assignee: Ryan Emerson
> Upsert does not work for MySQL
> ------------------------------
>
> Key: ISPN-6743
> URL: https://issues.jboss.org/browse/ISPN-6743
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 9.0.0.Alpha2
> Reporter: Krzysztof Sobolewski
> Assignee: Ryan Emerson
>
> ISPN-20, merged recently (thanks!), added "upsert" support for JDBC cache stores. The "upsert" SQL statement is database-type-dependent and the one for MySQL has a different "API" than the one for other database types - whereas all the others use the same number and order of placeholders as the equvalent INSERT statement, so that the same method can be used to update the INSERT, UPDATE and "upsert" statement, the MySQL one adds additional placeholders and the aforementioned method is no longer sufficient.
> The exception is:
> java.sql.SQLException: No value specified for parameter 4
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (ISPN-6845) A JDBC-based CacheLoader/CacheWriter that breaks down keys and values into multiple table columns
by Krzysztof Sobolewski (JIRA)
[ https://issues.jboss.org/browse/ISPN-6845?page=com.atlassian.jira.plugin.... ]
Krzysztof Sobolewski edited comment on ISPN-6845 at 7/7/16 7:30 AM:
--------------------------------------------------------------------
I have a prototype implementation of this, but it's a direct extension of the existing classes/interfaces and the result is not really merge-worthy. It does the followng things:
* The configuration of key/data name/type is changed from a single String to a List<String> so that we can declare multiple columns for the key and the value
* The configuration builder uses varargs so source compatibility (not binary compatibility) is preserved
* The Key2StringMapper interface is extended so that it can return multiple values (Objects, not String) for the key
* The Key2StringMapper is also applied to the values
* The TableManagers are modified to generate multi-column statements, which is a little more involved than a simple String.format() :)
Overall, it works, but is a little awkward (Key2StringMapper applied to values? Key2StringMapper that generates Object[]? The mapper for values takes an extra "parameter" that is crammed in front of the array ob objects extracted from the database. The boolean fetchValues and boolean fetchMetadata parameters are ignored. Etc).
The code is in https://github.com/ksobolew/infinispan/tree/ISPN-6845 if someone wishes to take a look.
was (Author: ksobolewski):
I have a prototype implementation of this, but it's a direct extension of the existing classes/interfaces and the result is not really merge-worthy. It does the followng things:
* The configuration of key/data name/type is changed from a single String to a List<String> so that we can declare multiple columns for the key and the value
* The configuration builder uses varargs so source compatibility (not binary compatibility) is preserved
* The Key2StringMapper interface is extended so that it can return multiple values (Objects, not String) for the key
* The Key2StringMapper is also applied to the values
Overall, it works, but is a little awkward (Key2StringMapper applied to values? Key2StringMapper that generates Object[]? The mapper for values takes an extra "parameter" that is crammed in front of the array ob objects extracted from the database. The boolean fetchValues and boolean fetchMetadata parameters are ignored. Etc).
The code is in https://github.com/ksobolew/infinispan/tree/ISPN-6845 if someone wishes to take a look.
> A JDBC-based CacheLoader/CacheWriter that breaks down keys and values into multiple table columns
> -------------------------------------------------------------------------------------------------
>
> Key: ISPN-6845
> URL: https://issues.jboss.org/browse/ISPN-6845
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Affects Versions: 9.0.0.Alpha2
> Reporter: Krzysztof Sobolewski
>
> Even in the JBoss Cache days we (at my $DAYJOB) were not really happy with how the JDBC cache loader stores the data. Yes, marshalling the value into a BLOB is universal and portable, but nevertheless we created our own variant that increases visibility into the data by storing each attribute of the value in its own database table, in a human-readable format. It also very slightly improves performance, but that's not the primary goal. I think something like this would be useful in Infinispan.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (ISPN-6845) A JDBC-based CacheLoader/CacheWriter that breaks down keys and values into multiple table columns
by Krzysztof Sobolewski (JIRA)
[ https://issues.jboss.org/browse/ISPN-6845?page=com.atlassian.jira.plugin.... ]
Krzysztof Sobolewski edited comment on ISPN-6845 at 7/7/16 7:23 AM:
--------------------------------------------------------------------
I have a prototype implementation of this, but it's a direct extension of the existing classes/interfaces and the result is not really merge-worthy. It does the followng things:
* The configuration of key/data name/type is changed from a single String to a List<String> so that we can declare multiple columns for the key and the value
* The configuration builder uses varargs so source compatibility (not binary compatibility) is preserved
* The Key2StringMapper interface is extended so that it can return multiple values (Objects, not String) for the key
* The Key2StringMapper is also applied to the values
Overall, it works, but is a little awkward (Key2StringMapper applied to values? Key2StringMapper that generates Object[]? The mapper for values takes an extra "parameter" that is crammed in front of the array ob objects extracted from the database. The boolean fetchValues and boolean fetchMetadata parameters are ignored. Etc).
The code is in https://github.com/ksobolew/infinispan/tree/ISPN-6845 if someone wishes to take a look.
was (Author: ksobolewski):
I have a prototype implementation of this, but it's a direct extension of the existing classes/interfaces and the result is not really merge-worthy. It does the followng things:
* The configuration of key/data name/type is changed from a single String to a List<String> so that we can declare multiple columns for the key and the value
* The configuration builder uses varargs so source compatibility (not binary compatibility) is preserved
* The Key2StringMapper interface is extended so that it can return multiple values (Objects, not String) for the key
* The Key2StringMapper is also applied to the values
Overall, it works, but is a little awkward (Key2StringMapper applied to values? Key2StringMapper that generates Object[]? etc).
The code is in https://github.com/ksobolew/infinispan/tree/ISPN-6845 if someone wishes to take a look.
> A JDBC-based CacheLoader/CacheWriter that breaks down keys and values into multiple table columns
> -------------------------------------------------------------------------------------------------
>
> Key: ISPN-6845
> URL: https://issues.jboss.org/browse/ISPN-6845
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Affects Versions: 9.0.0.Alpha2
> Reporter: Krzysztof Sobolewski
>
> Even in the JBoss Cache days we (at my $DAYJOB) were not really happy with how the JDBC cache loader stores the data. Yes, marshalling the value into a BLOB is universal and portable, but nevertheless we created our own variant that increases visibility into the data by storing each attribute of the value in its own database table, in a human-readable format. It also very slightly improves performance, but that's not the primary goal. I think something like this would be useful in Infinispan.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (ISPN-6845) A JDBC-based CacheLoader/CacheWriter that breaks down keys and values into multiple table columns
by Krzysztof Sobolewski (JIRA)
[ https://issues.jboss.org/browse/ISPN-6845?page=com.atlassian.jira.plugin.... ]
Krzysztof Sobolewski edited comment on ISPN-6845 at 7/7/16 7:16 AM:
--------------------------------------------------------------------
I have a prototype implementation of this, but it's a direct extension of the existing classes/interfaces and the result is not really merge-worthy. It does the followng things:
* The configuration of key/data name/type is changed from a single String to a List<String> so that we can declare multiple columns for the key and the value
* The configuration builder uses varargs so source compatibility (not binary compatibility) is preserved
* The Key2StringMapper interface is extended so that it can return multiple values (Objects, not String) for the key
* The Key2StringMapper is also applied to the values
Overall, it works, but is a little awkward (Key2StringMapper applied to values? Key2StringMapper that generates Object[]? etc).
The code is in https://github.com/ksobolew/infinispan/tree/ISPN-6845 if someone wishes to take a look.
was (Author: ksobolewski):
I have a prototype implementation of this, but it's a direct extension of the existing classes/interfaces and the result is not really merge-worthy. It does the followng things:
* The configuration of key/data name/type is changed from a single String to a List<String> so that we can declare multiple columns for the key and the value
* The configuration builder uses varargs so source compatibility (not binary compatibility) is preserved
* The Key2StringMapper interface is extended so that it can return multiple values (Objects, not String) for the key
* The Key2StringMapper is also applied to the values
Overall, it works, but is a little awkward (*Key*2StringMapper applied to *values*? Key2*String*Mapper that generates Object[]? etc).
The code is in https://github.com/ksobolew/infinispan/tree/ISPN-6845 if someone wishes to take a look.
> A JDBC-based CacheLoader/CacheWriter that breaks down keys and values into multiple table columns
> -------------------------------------------------------------------------------------------------
>
> Key: ISPN-6845
> URL: https://issues.jboss.org/browse/ISPN-6845
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Affects Versions: 9.0.0.Alpha2
> Reporter: Krzysztof Sobolewski
>
> Even in the JBoss Cache days we (at my $DAYJOB) were not really happy with how the JDBC cache loader stores the data. Yes, marshalling the value into a BLOB is universal and portable, but nevertheless we created our own variant that increases visibility into the data by storing each attribute of the value in its own database table, in a human-readable format. It also very slightly improves performance, but that's not the primary goal. I think something like this would be useful in Infinispan.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (ISPN-6845) A JDBC-based CacheLoader/CacheWriter that breaks down keys and values into multiple table columns
by Krzysztof Sobolewski (JIRA)
[ https://issues.jboss.org/browse/ISPN-6845?page=com.atlassian.jira.plugin.... ]
Krzysztof Sobolewski commented on ISPN-6845:
--------------------------------------------
I have a prototype implementation of this, but it's a direct extension of the existing classes/interfaces and the result is not really merge-worthy. It does the followng things:
* The configuration of key/data name/type is changed from a single String to a List<String> so that we can declare multiple columns for the key and the value
* The configuration builder uses varargs so source compatibility (not binary compatibility) is preserved
* The Key2StringMapper interface is extended so that it can return multiple values (Objects, not String) for the key
* The Key2StringMapper is also applied to the values
Overall, it works, but is a little awkward (*Key*2StringMapper applied to *values*? Key2*String*Mapper that generates Object[]? etc).
The code is in https://github.com/ksobolew/infinispan/tree/ISPN-6845 if someone wishes to take a look.
> A JDBC-based CacheLoader/CacheWriter that breaks down keys and values into multiple table columns
> -------------------------------------------------------------------------------------------------
>
> Key: ISPN-6845
> URL: https://issues.jboss.org/browse/ISPN-6845
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Affects Versions: 9.0.0.Alpha2
> Reporter: Krzysztof Sobolewski
>
> Even in the JBoss Cache days we (at my $DAYJOB) were not really happy with how the JDBC cache loader stores the data. Yes, marshalling the value into a BLOB is universal and portable, but nevertheless we created our own variant that increases visibility into the data by storing each attribute of the value in its own database table, in a human-readable format. It also very slightly improves performance, but that's not the primary goal. I think something like this would be useful in Infinispan.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (ISPN-6845) A JDBC-based CacheLoader/CacheWriter that breaks down keys and values into multiple table columns
by Krzysztof Sobolewski (JIRA)
Krzysztof Sobolewski created ISPN-6845:
------------------------------------------
Summary: A JDBC-based CacheLoader/CacheWriter that breaks down keys and values into multiple table columns
Key: ISPN-6845
URL: https://issues.jboss.org/browse/ISPN-6845
Project: Infinispan
Issue Type: Feature Request
Components: Loaders and Stores
Affects Versions: 9.0.0.Alpha2
Reporter: Krzysztof Sobolewski
Even in the JBoss Cache days we (at my $DAYJOB) were not really happy with how the JDBC cache loader stores the data. Yes, marshalling the value into a BLOB is universal and portable, but nevertheless we created our own variant that increases visibility into the data by storing each attribute of the value in its own database table, in a human-readable format. It also very slightly improves performance, but that's not the primary goal. I think something like this would be useful in Infinispan.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (ISPN-6844) Remove redundant enabled flag and disableInterceptor method from CacheWriter/Loader Interceptors
by Ryan Emerson (JIRA)
Ryan Emerson created ISPN-6844:
----------------------------------
Summary: Remove redundant enabled flag and disableInterceptor method from CacheWriter/Loader Interceptors
Key: ISPN-6844
URL: https://issues.jboss.org/browse/ISPN-6844
Project: Infinispan
Issue Type: Enhancement
Components: Loaders and Stores
Reporter: Ryan Emerson
Assignee: Ryan Emerson
Currently both the CacheWriter and CacheLoader interceptors utilise a method disableInterceptor which sets a boolean flag to false. This method is only every called by PersistenceManagerImpl when removing the interceptor, at which point it should not be possible for any of the removed interceptor's methods to be executed. Therefore we should be able to remove this flag, associated checks and the disableInterceptor method without issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (ISPN-6843) JdbcStringBasedStore process does not iterate entries in parallel
by Ryan Emerson (JIRA)
Ryan Emerson created ISPN-6843:
----------------------------------
Summary: JdbcStringBasedStore process does not iterate entries in parallel
Key: ISPN-6843
URL: https://issues.jboss.org/browse/ISPN-6843
Project: Infinispan
Issue Type: Enhancement
Components: Loaders and Stores
Affects Versions: 9.0.0.Alpha2
Reporter: Ryan Emerson
Assignee: Ryan Emerson
Current the process method is simply submitted to the executor and executed as one. Instead, the resultset of the query should be iterated in parallel like in JdbcBinaryStore.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months