[jboss-jira] [JBoss JIRA] Updated: (JBCACHE-964) Create Transforming CacheLoaders that transform 1.x formatted data into 2.x format

[Galder Zamarreno (JIRA)]

     [ 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