[infinispan-dev] Integrating Karsten's FCS

[Sanne Grinovero]

Thanks Galder for opening the JIRA; but I wonder if we actually have a way out.

5.3.0.Final was released already, so if you want to "fix" its format
to be compatible with 5.2 in a minor patch version - probably 5.3.1 -
then that would break compatibility with 5.3.0 which is maybe even
worse.

Probably the lesser evil is to clearly warn about this and suggest an
external dump; this way we also save some work as we could drop the
existing CacheStore implementation and move on.. the saved dev time
could be spent on tests to make sure this problem won't occur again as
it clearly is a major problem if it slips into a released version
without being spotted on time.

Cheers,
Sanne


On 11 July 2013 10:53, Mircea Markus <mmarkus at redhat.com> wrote:
>
> On 11 Jul 2013, at 10:22, Galder Zamarreño <galder at redhat.com> wrote:
>
>>> |
>>> | Hi,
>>> |
>>> | I think we all agree that Karsten's file cache store is a good base
>>> | replacement for the current file cache store, particularly for caches with
>>> | relatively small keys, or not a huge amount of them.
>>> |
>>> | I'm working with Radim to try to figure out what would be the tipping point
>>> | at which LevelDB based cache store behaves better compared to Karsten's
>>> | cache store.
>>> |
>>> | In the mean time, I think we should integrate Karsten's FCS into master and
>>> | have it ready for people to try from Alpha1. There's one or two things that
>>> | do require a bit of review, but I can pin point them in the pull req.
>>> |
>>> | The question is, how should we name it? And what should we do about the
>>> | current FCS implementation?
>>> |
>>> | Shall we keep the current FCS implementation, deprecate it, and get rid of it
>>> | in the next minor/major version? Some users might have data stored in the
>>> | current FCS and would be quite abrupt to just get rid of it right now.
>>>
>>> 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.
>
>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (www.infinispan.org)
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev