[infinispan-dev] Remote execute null return (ISPN-6406)
Galder Zamarreño
galder at redhat.com
Thu Apr 21 11:08:14 EDT 2016
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
More information about the infinispan-dev
mailing list