Hi Randall,
I would agree with you that this should be a priority, but keep in
mind that just migrating data from a CacheStore to another won't be
enough: as I pointed out in my previous mail, binary encoding also
changed, making it impossible to deserialize the values.
I'm not sure if the encoding change was meant to happen, but
apparently there is currently no effort in place to test for this kind
of backward compatibility.
If you need such a thing for ModeShape it would likely be easier for
you to provide such a tool in ModeShape to extract all data and dump
it to some external file, than to provide the hooks in Infinispan as
the transcoding tool would need to depend on multiple Infinispan
versions.
Sanne
On 9 July 2013 14:37, Randall Hauch <rhauch(a)redhat.com> wrote:
On Jul 9, 2013, at 4:07 AM, Radim Vansa <rvansa(a)redhat.com> wrote:
> ----- Original Message -----
> | From: "Galder ZamarreƱo" <galder(a)redhat.com>
> | 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.
Can you describe this process, especially for how it can be accomplished with a single
(local) cache?
A migration mechanism is absolutely a must. There are ModeShape users that have used the
FCS simply because it suits their needs - primarily because there are no extra
dependencies and no additional "system" underneath. There HAS to be a migration
path, especially if the old FCS is going to be removed.
Why does Infinispan not have a general-purpose mechanism for converting from one
(offline) cache store to another (offline) cache store?
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev