On 9 March 2017 at 10:22, Dan Berindei <dan.berin...@gmail.com> wrote: > On Thu, Mar 9, 2017 at 11:48 AM, Sanne Grinovero <sa...@infinispan.org> wrote: >> Hi Dan! >> > > Hey Sanne :) > >> On 9 March 2017 at 09:38, Dan Berindei <dan.berin...@gmail.com> wrote: >>> Every store can have its own Key2StringMapper, so I really don't think >>> service discovery is appropriate here. >> >> I suggested a default, while maintaining the property as an override option. >> >> It won't make any difference to people in the situation you describe, >> but it will avoid trouble for many more users. >> >> In my experience when one develops a custom type & a custom >> Key2StringMapper, you really wouldn't have interest in creating >> multiple implementations for the same type. The only case in which I >> can see some use for allowing multiple conflicting registrations to >> the same type is for upgrade / migration cases.. >> > > The problem I see is that each store can only have one > Key2StringMapper implementation, so you're going to have conflicts > even if your caches use completely different key types. The store > doesn't know which key types the application actually uses, so it > can't pick the appropriate implementation when there are multiple ones > on the classpath.
Good point. I was hoping to allow different services to "contribute" their different converters but I realise now that it would introduce a risk of ambiguous representations. They would need some standard scoping to know to which one to delegate to on read operations. I wonder if we could enforce / validate that? >>> My favourite solution would be to have a default Key2StringMapper >>> implementation that uses Java serialization (not our internal >>> marshalling, because that can change between versions). It could even >>> do base64 encoding for databases that don't have a VARBINARY/BYTEA >>> equivalent. >>> > > Do you see any problem with using serialization everywhere? I guess we could discuss alternative strategies, but it's an orthogonal discussion right? You're proposing a different CacheStore implementation, but people would still need a better way to associate the adaptors to the types. But to answer your question: yes I wouldn't like using Java serialization: people need to be able to evolve their domain model. When we had to "break" the string format in the Lucene mappers (as I added a new field) we managed to do it in an evolutionary way: it wasn't too hard to make sure we could read the old string format, while with Java serialization this would have been a mess. Also it would be nice to keep the representation as short as possible for both efficient processing and storage space efficiency: Java Serialization isn't particularly compact. Thanks, Sanne > > Dan > > >>> Cheers >>> Dan >>> >>> >>> On Wed, Mar 8, 2017 at 6:34 PM, Sanne Grinovero <sa...@infinispan.org> >>> wrote: >>>> It seems I keep forgetting that the "key2StringMapperClass" needs to >>>> be explicitly set when using the String based JDBC CacheStore, which I >>>> think is a quite popular store. >>>> >>>> http://infinispan.org/docs/dev/user_guide/user_guide.html#storing_the_index_in_a_database >>>> >>>> I think we could remove the need to configure this with an appropriate >>>> service discovery? >>>> >>>> We could keep the property so to be able to override the discovery process. >>>> >>>> Would anyone volunteer to implement this? >>>> >>>> Thanks, >>>> Sanne >>>> _______________________________________________ >>>> 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 >> _______________________________________________ >> 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 _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
