[JBoss JIRA] Created: (JBCACHE-964) Optional 1.x marshalling for CacheLoaders using VersionAwareMarshaller
9:57 a.m.
Optional 1.x marshalling for CacheLoaders using VersionAwareMarshaller
----------------------------------------------------------------------
Key: JBCACHE-964
URL: http://jira.jboss.com/jira/browse/JBCACHE-964
Project: JBoss Cache
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Cache loaders
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Minor
Fix For: 2.0.0.BETA2, 2.0.0.GA
Customers that want to use JBossCache 2.x might be reluctant to
migrate their data from one format to the other. I can see how an
existing customer might think this is a proper pain in the ass,
independent of the benefits, and might reduce adoption among them.
We want to remove barriers upgrading, but at the same time, we want
new customer to use new marshalling, so I'd actually implement the
possibility to use 1.x marshalling which is plan java serialization at
the CacheLoader level. This could easily achieved adding a property to
the <properties> section.
The default in 2.x should be to use VAM and only people who are
resilient to change their existing stores to VAM should use the 1.x
option, which would need explicitly definition.
This option also makes it easier for migration purpouses as customers
should be able to start two cache instances with different cache loader
marshalling method set. They could then loop through the first one using
get operations and call put in the second instance.
Just note that this does not apply to the marshalling done at
replication level as there's no hard data that needs migrating.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:45 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-964) Optional 1.x marshalling for CacheLoaders using VersionAwareMarshaller
[ http://jira.jboss.com/jira/browse/JBCACHE-964?page=comments#action_12354738 ]
Galder Zamarreno commented on JBCACHE-964:
------------------------------------------
With the addition of the new AdjListJDBCCacheLoader,
i'll look at the possibility of just enabling the use of
cache.loader.marshalling.plainserialization system property,
which enables 1.x marshalling, when used with the old
JDBCCacheLoader.
The new version should just use VAM.
Optional 1.x marshalling for CacheLoaders using
VersionAwareMarshaller
----------------------------------------------------------------------
Key: JBCACHE-964
URL: http://jira.jboss.com/jira/browse/JBCACHE-964
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Cache loaders
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Minor
Fix For: 2.0.0.GA, 2.0.0.BETA2
Customers that want to use JBossCache 2.x might be reluctant to
migrate their data from one format to the other. I can see how an
existing customer might think this is a proper pain in the ass,
independent of the benefits, and might reduce adoption among them.
We want to remove barriers upgrading, but at the same time, we want
new customer to use new marshalling, so I'd actually implement the
possibility to use 1.x marshalling which is plan java serialization at
the CacheLoader level. This could easily achieved adding a property to
the <properties> section.
The default in 2.x should be to use VAM and only people who are
resilient to change their existing stores to VAM should use the 1.x
option, which would need explicitly definition.
This option also makes it easier for migration purpouses as customers
should be able to start two cache instances with different cache loader
marshalling method set. They could then loop through the first one using
get operations and call put in the second instance.
Just note that this does not apply to the marshalling done at
replication level as there's no hard data that needs migrating.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:05 a.m.
New subject: [JBoss JIRA] Updated: (JBCACHE-964) Optional 1.x marshalling for CacheLoaders using VersionAwareMarshaller
[ http://jira.jboss.com/jira/browse/JBCACHE-964?page=all ]
Galder Zamarreno updated JBCACHE-964:
-------------------------------------
Comment: was deleted
Optional 1.x marshalling for CacheLoaders using
VersionAwareMarshaller
----------------------------------------------------------------------
Key: JBCACHE-964
URL: http://jira.jboss.com/jira/browse/JBCACHE-964
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Cache loaders
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Minor
Fix For: 2.0.0.GA, 2.0.0.BETA2
Customers that want to use JBossCache 2.x might be reluctant to
migrate their data from one format to the other. I can see how an
existing customer might think this is a proper pain in the ass,
independent of the benefits, and might reduce adoption among them.
We want to remove barriers upgrading, but at the same time, we want
new customer to use new marshalling, so I'd actually implement the
possibility to use 1.x marshalling which is plan java serialization at
the CacheLoader level. This could easily achieved adding a property to
the <properties> section.
The default in 2.x should be to use VAM and only people who are
resilient to change their existing stores to VAM should use the 1.x
option, which would need explicitly definition.
This option also makes it easier for migration purpouses as customers
should be able to start two cache instances with different cache loader
marshalling method set. They could then loop through the first one using
get operations and call put in the second instance.
Just note that this does not apply to the marshalling done at
replication level as there's no hard data that needs migrating.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:57 p.m.
New subject: [JBoss JIRA] Updated: (JBCACHE-964) Create Transforming CacheLoaders that transform 1.x formatted data into 2.x format
[ http://jira.jboss.com/jira/browse/JBCACHE-964?page=all ]
Galder Zamarreno updated JBCACHE-964:
-------------------------------------
Summary: Create Transforming CacheLoaders that transform 1.x formatted data into 2.x
format (was: Optional 1.x marshalling for CacheLoaders using VersionAwareMarshaller)
A completely new approach is being implemented now:
"After discussions with Brian we came up with a different approach for this.
My previous approach (don't need to read all below) relied on introducing legacy code
into the main source code that would be able to read 1.x serialization. As I started doing
it, I realised that it would need a lot of changes and it would clutter the 2.0 codebase.
Instead, with the help of Brian, we came up with a different idea, which is creating two
one-off cache loaders, TransformingJDBCCacheLoader and TransformingFileCacheLoader. They
extend the existing cache loaders, but they differentiate by unmarshall stuff in the 1.x
way.
This way, we have cache loaders that can read in 1.x way and write in 2.x way. Now, a
customer just needs to write a program that uses a cache configured to use any of these
two cache loaders above and all it has to do is loop through the tree reading all nodes
and putting them back, and voila! you have your data store format changed (I'll be
writing an example of this).
It's a pretty clean solution to transforming data without making changes to main
o.j.cache tree.
But, there's always a but :) , 1.4.x used org.jboss.invocation.MarshalledValue so
there's no way of getting around the need of having this class to do this. This is
because JDBCCacheLoader stored instances of MarshalledValue, so even the MV class in AOP
would not work cos it's a different package (it'd result in CCE)
One thing Brian suggested is that these two cache loaders and jboss-minimal are kept in a
separate dir structure to the main one and when we distribute, we provide an extra jar
containing these that can be used to transform data and that's it. After that, you get
rid of it, you go back to the standard libraries.
It's pretty hard to find a neater way of dealing with this but the benefits are worth
it, customer's data stays alive! "
Create Transforming CacheLoaders that transform 1.x formatted data
into 2.x format
----------------------------------------------------------------------------------
Key: JBCACHE-964
URL: http://jira.jboss.com/jira/browse/JBCACHE-964
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Cache loaders
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Minor
Fix For: 2.0.0.GA, 2.0.0.BETA2
Customers that want to use JBossCache 2.x might be reluctant to
migrate their data from one format to the other. I can see how an
existing customer might think this is a proper pain in the ass,
independent of the benefits, and might reduce adoption among them.
We want to remove barriers upgrading, but at the same time, we want
new customer to use new marshalling, so I'd actually implement the
possibility to use 1.x marshalling which is plan java serialization at
the CacheLoader level. This could easily achieved adding a property to
the <properties> section.
The default in 2.x should be to use VAM and only people who are
resilient to change their existing stores to VAM should use the 1.x
option, which would need explicitly definition.
This option also makes it easier for migration purpouses as customers
should be able to start two cache instances with different cache loader
marshalling method set. They could then loop through the first one using
get operations and call put in the second instance.
Just note that this does not apply to the marshalling done at
replication level as there's no hard data that needs migrating.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:32 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-964) Create Transforming CacheLoaders that transform 1.x formatted data into 2.x format
[ http://jira.jboss.com/jira/browse/JBCACHE-964?page=comments#action_12355390 ]
Galder Zamarreno commented on JBCACHE-964:
------------------------------------------
I'm gonna commit the first part of the work:
- Transforming Cache Loaders implemented and unit tests provided
- Structure created:
[JBC-SOURCE-ROOT]
+ migration
+ src
+ o.j.c.migration.TransformingJDBCCacheLoader
+ o.j.c.migration.TransformingFileCacheLoader
+ o.j.c.migration.LegacyJDBCCacheLoader (JDBCCacheLoaderOld)
+ lib
+ jboss-minimal.jar (from 1.4.x)
+ tests (UT)
+ o.j.c.migration.TransformingCacheLoaderTestBase
+ o.j.c.migration.TransformingFileCacheLoaderTest
+ o.j.c.migration.TransformingJDBCCacheLoaderTest
+ examples
+ cacheloader-migration
// includes files to run the examples and readme.txt with
// explanation
+ data
+ filecacheloader-1x.zip
+ jbossdb-1x.zip
+ resources
+ original-fcl-service.xml (sample original FCL XML)
+ original-jdbccl-service.xml (sample original JDBCCL XML)
+ transform-fcl-service.xml (mod of original to transform)
+ transform-jdbccl-service.xml (mod of original to transform)
+ src
+ examples.TransformStore
- build.xml modified to compile, jar, create manifest for migration jar
and also added examples and migration jar to distros.
- example created and tested; it includes readme.txt with details of the
example and how to run it.
TODO:
- Unit tests for transforming cache loaders need to run from build.xml
- Documentation for transforming cache loaders in users guide, what are
they, when to use them,...etc.
- Fix http://jira.jboss.com/jira/browse/JBCACHE-877 that occurrs when unzipping
JBossCache-core-2.0.0.BETA2.zip and running the examples. Workaround is to bring trove.jar
into its lib.
- Get examples/cacheloader-migration/build.sh working
- Move JDBCCacheLoaderOld to the migration side. It's not that straightforward due to
classes in
/src having dependencies on it. Needs further study.
Create Transforming CacheLoaders that transform 1.x formatted data
into 2.x format
----------------------------------------------------------------------------------
Key: JBCACHE-964
URL: http://jira.jboss.com/jira/browse/JBCACHE-964
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Cache loaders
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Minor
Fix For: 2.0.0.GA, 2.0.0.BETA2
Customers that want to use JBossCache 2.x might be reluctant to
migrate their data from one format to the other. I can see how an
existing customer might think this is a proper pain in the ass,
independent of the benefits, and might reduce adoption among them.
We want to remove barriers upgrading, but at the same time, we want
new customer to use new marshalling, so I'd actually implement the
possibility to use 1.x marshalling which is plan java serialization at
the CacheLoader level. This could easily achieved adding a property to
the <properties> section.
The default in 2.x should be to use VAM and only people who are
resilient to change their existing stores to VAM should use the 1.x
option, which would need explicitly definition.
This option also makes it easier for migration purpouses as customers
should be able to start two cache instances with different cache loader
marshalling method set. They could then loop through the first one using
get operations and call put in the second instance.
Just note that this does not apply to the marshalling done at
replication level as there's no hard data that needs migrating.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:50 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-964) Create Transforming CacheLoaders that transform 1.x formatted data into 2.x format
[ http://jira.jboss.com/jira/browse/JBCACHE-964?page=comments#action_12355474 ]
Manik Surtani commented on JBCACHE-964:
---------------------------------------
Are you also writing a "Migrator" application to do the looping - traverse the
tree, read each node and put it back in the cache?
Create Transforming CacheLoaders that transform 1.x formatted data
into 2.x format
----------------------------------------------------------------------------------
Key: JBCACHE-964
URL: http://jira.jboss.com/jira/browse/JBCACHE-964
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Cache loaders
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Minor
Fix For: 2.0.0.GA, 2.0.0.BETA2
Customers that want to use JBossCache 2.x might be reluctant to
migrate their data from one format to the other. I can see how an
existing customer might think this is a proper pain in the ass,
independent of the benefits, and might reduce adoption among them.
We want to remove barriers upgrading, but at the same time, we want
new customer to use new marshalling, so I'd actually implement the
possibility to use 1.x marshalling which is plan java serialization at
the CacheLoader level. This could easily achieved adding a property to
the <properties> section.
The default in 2.x should be to use VAM and only people who are
resilient to change their existing stores to VAM should use the 1.x
option, which would need explicitly definition.
This option also makes it easier for migration purpouses as customers
should be able to start two cache instances with different cache loader
marshalling method set. They could then loop through the first one using
get operations and call put in the second instance.
Just note that this does not apply to the marshalling done at
replication level as there's no hard data that needs migrating.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:54 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-964) Create Transforming CacheLoaders that transform 1.x formatted data into 2.x format
[ http://jira.jboss.com/jira/browse/JBCACHE-964?page=comments#action_12355475 ]
Galder Zamarreno commented on JBCACHE-964:
------------------------------------------
that's done and committed :)
build head (dist target), take JBossCache-all-2.0.0.BETA2
and you should see an examples/cacheloader-migration
readme.txt explains how to run the application, what it
does...etc
Create Transforming CacheLoaders that transform 1.x formatted data
into 2.x format
----------------------------------------------------------------------------------
Key: JBCACHE-964
URL: http://jira.jboss.com/jira/browse/JBCACHE-964
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Cache loaders
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Minor
Fix For: 2.0.0.GA, 2.0.0.BETA2
Customers that want to use JBossCache 2.x might be reluctant to
migrate their data from one format to the other. I can see how an
existing customer might think this is a proper pain in the ass,
independent of the benefits, and might reduce adoption among them.
We want to remove barriers upgrading, but at the same time, we want
new customer to use new marshalling, so I'd actually implement the
possibility to use 1.x marshalling which is plan java serialization at
the CacheLoader level. This could easily achieved adding a property to
the <properties> section.
The default in 2.x should be to use VAM and only people who are
resilient to change their existing stores to VAM should use the 1.x
option, which would need explicitly definition.
This option also makes it easier for migration purpouses as customers
should be able to start two cache instances with different cache loader
marshalling method set. They could then loop through the first one using
get operations and call put in the second instance.
Just note that this does not apply to the marshalling done at
replication level as there's no hard data that needs migrating.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-964) Create Transforming CacheLoaders that transform 1.x formatted data into 2.x format
[ http://jira.jboss.com/jira/browse/JBCACHE-964?page=comments#action_12355476 ]
Galder Zamarreno commented on JBCACHE-964:
------------------------------------------
Note that using just JBossCache-core-2.0.0.BETA2 throws:
http://jira.jboss.com/jira/browse/JBCACHE-877
Create Transforming CacheLoaders that transform 1.x formatted data
into 2.x format
----------------------------------------------------------------------------------
Key: JBCACHE-964
URL: http://jira.jboss.com/jira/browse/JBCACHE-964
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Cache loaders
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Minor
Fix For: 2.0.0.GA, 2.0.0.BETA2
Customers that want to use JBossCache 2.x might be reluctant to
migrate their data from one format to the other. I can see how an
existing customer might think this is a proper pain in the ass,
independent of the benefits, and might reduce adoption among them.
We want to remove barriers upgrading, but at the same time, we want
new customer to use new marshalling, so I'd actually implement the
possibility to use 1.x marshalling which is plan java serialization at
the CacheLoader level. This could easily achieved adding a property to
the <properties> section.
The default in 2.x should be to use VAM and only people who are
resilient to change their existing stores to VAM should use the 1.x
option, which would need explicitly definition.
This option also makes it easier for migration purpouses as customers
should be able to start two cache instances with different cache loader
marshalling method set. They could then loop through the first one using
get operations and call put in the second instance.
Just note that this does not apply to the marshalling done at
replication level as there's no hard data that needs migrating.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:18 a.m.
New subject: [JBoss JIRA] Updated: (JBCACHE-964) Create Transforming CacheLoaders that transform 1.x formatted data into 2.x format
[ http://jira.jboss.com/jira/browse/JBCACHE-964?page=all ]
Manik Surtani updated JBCACHE-964:
----------------------------------
Fix Version/s: 2.0.0.CR1
(was: 2.0.0.BETA2)
Create Transforming CacheLoaders that transform 1.x formatted data
into 2.x format
----------------------------------------------------------------------------------
Key: JBCACHE-964
URL: http://jira.jboss.com/jira/browse/JBCACHE-964
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Cache loaders
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Minor
Fix For: 2.0.0.CR1, 2.0.0.GA
Customers that want to use JBossCache 2.x might be reluctant to
migrate their data from one format to the other. I can see how an
existing customer might think this is a proper pain in the ass,
independent of the benefits, and might reduce adoption among them.
We want to remove barriers upgrading, but at the same time, we want
new customer to use new marshalling, so I'd actually implement the
possibility to use 1.x marshalling which is plan java serialization at
the CacheLoader level. This could easily achieved adding a property to
the <properties> section.
The default in 2.x should be to use VAM and only people who are
resilient to change their existing stores to VAM should use the 1.x
option, which would need explicitly definition.
This option also makes it easier for migration purpouses as customers
should be able to start two cache instances with different cache loader
marshalling method set. They could then loop through the first one using
get operations and call put in the second instance.
Just note that this does not apply to the marshalling done at
replication level as there's no hard data that needs migrating.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:04 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-964) Create Transforming CacheLoaders that transform 1.x formatted data into 2.x format
[ http://jira.jboss.com/jira/browse/JBCACHE-964?page=comments#action_12359994 ]
Galder Zamarreno commented on JBCACHE-964:
------------------------------------------
Done:
- Unit tests for transforming cache loaders need to run from build.xml
- Get examples/cacheloader-migration/build.sh working
Still TODO:
- Move JDBCCacheLoaderOld, AdjListJDBCCacheLoaderCompatibilityTest
and OldImplBenchmark to the migration side?
- Documentation for transforming cache loaders in users guide, what are
they, when to use them,...etc.
Create Transforming CacheLoaders that transform 1.x formatted data
into 2.x format
----------------------------------------------------------------------------------
Key: JBCACHE-964
URL: http://jira.jboss.com/jira/browse/JBCACHE-964
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Cache loaders
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Minor
Fix For: 2.0.0.CR1, 2.0.0.GA
Customers that want to use JBossCache 2.x might be reluctant to
migrate their data from one format to the other. I can see how an
existing customer might think this is a proper pain in the ass,
independent of the benefits, and might reduce adoption among them.
We want to remove barriers upgrading, but at the same time, we want
new customer to use new marshalling, so I'd actually implement the
possibility to use 1.x marshalling which is plan java serialization at
the CacheLoader level. This could easily achieved adding a property to
the <properties> section.
The default in 2.x should be to use VAM and only people who are
resilient to change their existing stores to VAM should use the 1.x
option, which would need explicitly definition.
This option also makes it easier for migration purpouses as customers
should be able to start two cache instances with different cache loader
marshalling method set. They could then loop through the first one using
get operations and call put in the second instance.
Just note that this does not apply to the marshalling done at
replication level as there's no hard data that needs migrating.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:48 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-964) Create Transforming CacheLoaders that transform 1.x formatted data into 2.x format
[ http://jira.jboss.com/jira/browse/JBCACHE-964?page=comments#action_12360067 ]
Galder Zamarreno commented on JBCACHE-964:
------------------------------------------
Done:
- Documentation for transforming cache loaders in users guide, what are
they, when to use them,...etc.
TODO:
- Move JDBCCacheLoaderOld, AdjListJDBCCacheLoaderCompatibilityTest
and OldImplBenchmark to the migration path.
Create Transforming CacheLoaders that transform 1.x formatted data
into 2.x format
----------------------------------------------------------------------------------
Key: JBCACHE-964
URL: http://jira.jboss.com/jira/browse/JBCACHE-964
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Cache loaders
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Minor
Fix For: 2.0.0.CR1, 2.0.0.GA
Time Spent: 3 days
Remaining Estimate: 0 minutes
Customers that want to use JBossCache 2.x might be reluctant to
migrate their data from one format to the other. I can see how an
existing customer might think this is a proper pain in the ass,
independent of the benefits, and might reduce adoption among them.
We want to remove barriers upgrading, but at the same time, we want
new customer to use new marshalling, so I'd actually implement the
possibility to use 1.x marshalling which is plan java serialization at
the CacheLoader level. This could easily achieved adding a property to
the <properties> section.
The default in 2.x should be to use VAM and only people who are
resilient to change their existing stores to VAM should use the 1.x
option, which would need explicitly definition.
This option also makes it easier for migration purpouses as customers
should be able to start two cache instances with different cache loader
marshalling method set. They could then loop through the first one using
get operations and call put in the second instance.
Just note that this does not apply to the marshalling done at
replication level as there's no hard data that needs migrating.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:43 a.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-964) Create Transforming CacheLoaders that transform 1.x formatted data into 2.x format
[ http://jira.jboss.com/jira/browse/JBCACHE-964?page=comments#action_12360130 ]
Galder Zamarreno commented on JBCACHE-964:
------------------------------------------
I've been looking at moving those classes but I need more
time to dig into it because there's a production class relying on
JDBCCacheLoaderOld, which is used by AdjListJDBCCacheLoaderConfig.
I have also spotted some refactoring which affected some of the my
classes created in the past that are now pointing to AdjListJDBCCacheLoaderConfig
instead of JDBCCacheLoaderConfig.
Create Transforming CacheLoaders that transform 1.x formatted data
into 2.x format
----------------------------------------------------------------------------------
Key: JBCACHE-964
URL: http://jira.jboss.com/jira/browse/JBCACHE-964
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Cache loaders
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Minor
Fix For: 2.0.0.CR1, 2.0.0.GA
Time Spent: 3 days, 4 hours
Remaining Estimate: 0 minutes
Customers that want to use JBossCache 2.x might be reluctant to
migrate their data from one format to the other. I can see how an
existing customer might think this is a proper pain in the ass,
independent of the benefits, and might reduce adoption among them.
We want to remove barriers upgrading, but at the same time, we want
new customer to use new marshalling, so I'd actually implement the
possibility to use 1.x marshalling which is plan java serialization at
the CacheLoader level. This could easily achieved adding a property to
the <properties> section.
The default in 2.x should be to use VAM and only people who are
resilient to change their existing stores to VAM should use the 1.x
option, which would need explicitly definition.
This option also makes it easier for migration purpouses as customers
should be able to start two cache instances with different cache loader
marshalling method set. They could then loop through the first one using
get operations and call put in the second instance.
Just note that this does not apply to the marshalling done at
replication level as there's no hard data that needs migrating.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:57 p.m.
New subject: [JBoss JIRA] Resolved: (JBCACHE-964) Create Transforming CacheLoaders that transform 1.x formatted data into 2.x format
[ http://jira.jboss.com/jira/browse/JBCACHE-964?page=all ]
Galder Zamarreno resolved JBCACHE-964.
--------------------------------------
Resolution: Done
finally finished :)
Create Transforming CacheLoaders that transform 1.x formatted data
into 2.x format
----------------------------------------------------------------------------------
Key: JBCACHE-964
URL: http://jira.jboss.com/jira/browse/JBCACHE-964
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Cache loaders
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Minor
Fix For: 2.0.0.CR1, 2.0.0.GA
Time Spent: 3 days, 4 hours
Remaining Estimate: 0 minutes
Customers that want to use JBossCache 2.x might be reluctant to
migrate their data from one format to the other. I can see how an
existing customer might think this is a proper pain in the ass,
independent of the benefits, and might reduce adoption among them.
We want to remove barriers upgrading, but at the same time, we want
new customer to use new marshalling, so I'd actually implement the
possibility to use 1.x marshalling which is plan java serialization at
the CacheLoader level. This could easily achieved adding a property to
the <properties> section.
The default in 2.x should be to use VAM and only people who are
resilient to change their existing stores to VAM should use the 1.x
option, which would need explicitly definition.
This option also makes it easier for migration purpouses as customers
should be able to start two cache instances with different cache loader
marshalling method set. They could then loop through the first one using
get operations and call put in the second instance.
Just note that this does not apply to the marshalling done at
replication level as there's no hard data that needs migrating.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:57 p.m.
New subject: [JBoss JIRA] Commented: (JBCACHE-964) Create Transforming CacheLoaders that transform 1.x formatted data into 2.x format
[ http://jira.jboss.com/jira/browse/JBCACHE-964?page=comments#action_12360163 ]
Galder Zamarreno commented on JBCACHE-964:
------------------------------------------
Refactoring of JDBCCacheLoaderOld won't be
done at this stage due to complexity and required
changes in main build structure.
Create Transforming CacheLoaders that transform 1.x formatted data
into 2.x format
----------------------------------------------------------------------------------
Key: JBCACHE-964
URL: http://jira.jboss.com/jira/browse/JBCACHE-964
Project: JBoss Cache
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Cache loaders
Reporter: Galder Zamarreno
Assigned To: Galder Zamarreno
Priority: Minor
Fix For: 2.0.0.GA, 2.0.0.CR1
Time Spent: 3 days, 4 hours
Remaining Estimate: 0 minutes
Customers that want to use JBossCache 2.x might be reluctant to
migrate their data from one format to the other. I can see how an
existing customer might think this is a proper pain in the ass,
independent of the benefits, and might reduce adoption among them.
We want to remove barriers upgrading, but at the same time, we want
new customer to use new marshalling, so I'd actually implement the
possibility to use 1.x marshalling which is plan java serialization at
the CacheLoader level. This could easily achieved adding a property to
the <properties> section.
The default in 2.x should be to use VAM and only people who are
resilient to change their existing stores to VAM should use the 1.x
option, which would need explicitly definition.
This option also makes it easier for migration purpouses as customers
should be able to start two cache instances with different cache loader
marshalling method set. They could then loop through the first one using
get operations and call put in the second instance.
Just note that this does not apply to the marshalling done at
replication level as there's no hard data that needs migrating.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7021
days inactive
7101
days old
13 comments
3 participants
participants (3)
-
Galder Zamarreno (JIRA) -
Galder Zamarreno (JIRA) -
Manik Surtani (JIRA)