On Jul 11, 2013, at 3:41 PM, Randall Hauch <rhauch(a)redhat.com> wrote:
On Jul 11, 2013, at 4:53 AM, Mircea Markus <mmarkus(a)redhat.com>
wrote:
> On 11 Jul 2013, at 10:22, Galder Zamarreño <galder(a)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).
Interesting idea. I'm adding it to
https://issues.jboss.org/browse/ISPN-3318
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org