[infinispan-dev] Remote execute null return (ISPN-6406)

[Galder Zamarreño]

Thanks guys for the feedback.

We already implictly support null in some of the commands, e.g. get returns a particular status code when the key is not found. 

Exec should have something like that eventually but for now the best would be to send back an empty byte[] when null is returned. That's better than what we do right now and as Sebastian rightly said, it should be not much different for the users.

Cheers,
--
Galder Zamarreño
Infinispan, Red Hat

> On 20 Apr 2016, at 23:53, Dennis Reed <dereed at redhat.com> wrote:
> 
> A related question -- do you want to support null in the protocol?  Not
> all languages even have a concept of null.
> 
> So you do need to make a decision whether to support null to the
> exclusion of languages that don't have it (or make Hot Rod more
> complicated to use in those languages), or disallow null to increase
> interoperability but with a restriction of functionality in those
> languages that do allow it.
> 
> -Dennis
> 
> 
> On 04/20/2016 08:00 AM, Sebastian Laskawiec wrote:
>> I think this is pretty common problem [3]. 
>> 
>> On the other hand most of the users won't be interested in
>> distinguishing nulls from empty strings (at least in my opinion). So how
>> about leaving it as is by default and creating some configuration
>> parameter for using new status code as you suggested (just in case
>> someone would have to distinguish those two).
>> 
>> This way we would be somewhat backwards compatible and we would have a
>> rescue option for some users who would need this feature.
>> 
>> [3] http://blog.bdoughan.com/2012/04/binding-to-json-xml-handling-null.html
>> 
>> On Tue, Apr 19, 2016 at 6:31 PM, Galder Zamarreño <galder at redhat.com
>> <mailto:galder at redhat.com>> wrote:
>> 
>>    Hi all,
>> 
>>    A Hot Rod protocol change might be required as a result of [1].
>> 
>>    In essence, the Hot Rod protocol does not specify how remote exec
>>    calls that return null should respond back to the client [2].
>> 
>>    Returning an empty byte[] won't cut it since returning an empty
>>    String would be represented that way, and that's different to null.
>> 
>>    I don't know how this could be handled without modifying the
>>    protocol, any ideas?
>> 
>>    If modifying the protocol, adding a new status code would be a way
>>    to handle it.
>> 
>>    Thoughts?
>> 
>>    [1] https://issues.jboss.org/browse/ISPN-6406
>>    [2]
>>    http://infinispan.org/docs/8.2.x/user_guide/user_guide.html#_hot_rod_protocol_2_0
>>    --
>>    Galder Zamarreño
>>    Infinispan, Red Hat
>> 
>> 
>>    _______________________________________________
>>    infinispan-dev mailing list
>>    infinispan-dev at lists.jboss.org <mailto: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