Reading value field should allow empty string
Closed this issue ยท 7 comments
๐ Bug Report
Affected Services [REQUIRED]
The issue is located in: device servicesIs this a regression?
NoDescription and Minimal Reproduction [REQUIRED]
Read the empty string value from any device service and the value field does not exist in the result:
$ curl http://0.0.0.0:59958/api/v2/device/name/test-device/String_Test | json_pp
{
"apiVersion" : "v2",
"event" : {
"apiVersion" : "v2",
"deviceName" : "test-device",
"id" : "f8da3ef6-f14e-47f8-9c23-d875946cab8b",
"origin" : 1650345351185116000,
"profileName" : "test-profile",
"readings" : [
{
"deviceName" : "test-device",
"id" : "c425b1f8-ad7a-44ea-9218-5a00f1b61cc3",
"origin" : 1650345351185115000,
"profileName" : "test-profile",
"resourceName" : "String_Test",
"valueType" : "String"
}
],
"sourceName" : "String_Test"
},
"statusCode" : 200
}
๐ฅ Exception or Error
๐ Your Environment
Deployment Environment:
EdgeX Version [REQUIRED]:
main branch
Anything else relevant?
@weichou1229 , @cloudxxx8 , looking at this fix for Jakarta 2.1.1 patch. Concerned that a non String type can be created with an empty value which is invalid. i.e Int32 where Value = "". Am I missing something here?
@lenny-intel for the non-string value, we need some additional validation.
Even if we block the empty string, it can still be a non-numerical string.
It's a different issue. This issue is to allow string valueType can contain empty string. Should we open another issue to add the other valueType validation?
@cloudxxx8 , good point!
Is this fix something we need to add in the Jakarta 2.1.1 patch?
Yes please submit an issue for further validation so we can discuss it in the next Core WG. THX!
@lenny-intel , the new issue opened #737
this is the issue since v1, and the validation logic is a kind of enhancement.
I'm fine with adding to Jakarta or not. If you think it should be, please just add the jakarta label to the issue.
@cloudxxx8 , do we have an end user/adopter that needs the blank string reading in Jakarta?
no one is complaining for this version so far, but for the empty string, we can easily bring it in
#737 would need more time
OK, moving it out of consideration for 2.1.1. THX!