Repository navigation
cluster discovery: discard non-list result #196
Description
From README:
A discovery function should return a single result of strings (i.e. single string return 'host:3301' or array of strings return {'host1:3301', 'host2:3301'}).
I think there is no reason to support single string result. However if we'll support it here it will push other connectors to support it too (because a user that see correct result with tarantool-java will expect they will be correct with another connector too).
I propose to forbid support of this single string response format and allow only a list of strings result.
Validation rules and to be defined and maybe should be strictier that now and consistent with other connectors. Maybe this should not be handled with the scope of this issue.
Activity
nicktorwald commentedon Jun 3, 2019
We can only fix docs here, I think.
Because there are no differences between
return 'host'andreturn {'host'}in terms of msgpack. Both results will be deserialized as a single item collectionArrayList = {'host'}.Totktonada commentedon Jun 3, 2019
'host' is a4686f7374, {'host'} is 91a4686f7374. If they are really undistinguishable, it is something strange on the connector side.
Filter wrong formatted discovery addresses
nicktorwald commentedon Jun 3, 2019
hm... It seems Lua returns an array in both cases
0x91 0xA4 0x68 0x6F 0x73 0x74when we use old iproto_call_16 (0x06) instead of iproto_call (0x0a).Totktonada commentedon Jun 3, 2019
That is so. We should newer use call_16, tarantool-1.6 is gone a long time ago. It seems we can remove it entirely.
Filter wrong formatted discovery addresses
Filter wrong formatted discovery addresses
Filter wrong formatted discovery addresses
Do not use call_16 by default
Do not use call_16 by default