[infinispan-dev] Integrating Karsten's FCS

[Randall Hauch]

On Jul 11, 2013, at 4:53 AM, Mircea Markus <mmarkus at redhat.com> wrote:
> On 11 Jul 2013, at 10:22, Galder Zamarreño <galder at redhat.com> wrote:
>>> I'd remove it in Final, it cannot be seriously used either. Users can migrate the data using rolling upgrades.
>> 
>> ^ I don't think you can remove it in 6.0 Final. If you wanna do any kind of migration or rolling upgrade from the curren FCS to the new one, you need to have the current FCS around, to be able to read data in that format/setup and then write it to the new cache store. The moment you can remove it is the moment you've decided that no more migrations are gonna happen.
> 
> You can have the logic around but don't expose it to the users as a shipped cache store. E.g. move it to a different package and rename it to whatever you want.

Let's look at this from a user's perspective. Is it possible that the new file store **replaces** the old one, so that the user doesn't (really) need to know the difference? 

How similar are the configuration properties of each? Might it be possible to:
rename and deprecate the existing one (e.g., "org.infinispan.loaders.file.LegacyFileCacheStore"), changing it to 'package' or 'protected' (iff the new one is stable enough that the old one should definitely not be used anymore), 
rename the new one to "org.infinispan.loaders.file.FileCacheStore" (so that existing configurations work without change), 
have some code in the new one detect the old file structure and automatically run a migration to convert from the old file structure to the new format (and possibly move the old files into a subdirectory)

If this is possible, this is by far the best option for users since it provides a simple (perhaps even transparent) migration path with little if any changes required to configurations, but at the same time it allows the developers to get what they want: a new FCS that replaces the old one (which goes away).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20130711/b36f1f47/attachment.html