[infinispan-dev] Auto-detection of appropriate key2StringMapperClass

Dan Berindei dan.berindei at gmail.com
Thu Mar 9 05:22:53 EST 2017


On Thu, Mar 9, 2017 at 11:48 AM, Sanne Grinovero <sanne at infinispan.org> wrote:
> Hi Dan!
>

Hey Sanne :)

> On 9 March 2017 at 09:38, Dan Berindei <dan.berindei at 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.

>>
>> 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?

Dan


>> Cheers
>> Dan
>>
>>
>> On Wed, Mar 8, 2017 at 6:34 PM, Sanne Grinovero <sanne at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


More information about the infinispan-dev mailing list