[infinispan-dev] Auto-detection of appropriate key2StringMapperClass

[Sanne Grinovero]

On 9 March 2017 at 10:22, Dan Berindei <dan.berindei at gmail.com> wrote:
> 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.

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 <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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev