Hmmm, we've already discussed moving from the current internal/external marshaller architecture, where even user types are marshalled with internal marshaller, to an internal/user marshaller architecture where user types are only marshalled by the user marshaller. This is mentioned in [1] and the switch to internal/user marshaller is already being tracked in [3].
Your suggestion feels like a subset of what [3] is trying to achieve. In [3], the idea is not only to use the user marshaller for clustering but of course, for persistence. Cheers, [3] https://issues.jboss.org/browse/ISPN-7409 -- Galder Zamarreño Infinispan, Red Hat > On 14 Mar 2017, at 12:26, Ryan Emerson <remer...@redhat.com> wrote: > > Hi All, > > Currently the CacheWriterInterceptor utilises the internal marshaller for > marshalling entries before they are sent to the configured cache stores. This > causes several problems [1], most notably that changes to the internal > marshaller make stored data incompatible across Infinispan versions. > > I propose that we decouple the internal and store marshaller. To allow 9.x > versions to remain compatible, we should default to the internal marshaller > (until 10.x at least), but optionally allow users to specify a custom > StreamingMarshaller implementation as part of their PersistenceConfiguration. > As we already have the protostuff and kryo bridges, users would specify an > enum for the marshaller they want to use as well as an optional class string > if a custom implementation is required. So for example: > > enum StoreMarshaller { > CUSTOM, > INTERNAL, > KRYO > PROTOSTUFF; > } > > new ConfigurationBuilder() > .persistence() > .marshaller(StoreMarshaller.CUSTOM) > .marshallerClass("org.example.Marshaller") > ... > > Finally, Gustavo brought flatbuffers[2] to my attention which could be a good > option to provide for users as one of the default StoreMarshaller > implementations. > > WDYT? > > Cheers > Ryan > > [1] > https://docs.google.com/document/d/1PR0eYgjhqXUR5w03npS7TdOs2KDZjfdMh0au8XAsyJY > [2] https://google.github.io/flatbuffers/ > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
