Closed ctucker3 closed 3 years ago
This is a tough issue to solve because of the JSON deserializer in Java. By default, Java can't tell the difference between an explicit null and a missing field. The server is currently configured to not update missing fields. I think this can be resolved with some custom deserializer code to detect the difference, but it will take some research to find a clever way to do that.
Example: This
...
"dataType": "Numerical",
"decimalPlaces": null,
"externalReferences":
...
is read the same as this
...
"dataType": "Numerical",
"externalReferences":
...
Ah got ya, so is this an issue for all of the endpoints?
yea unfortunately
With String fields you can kinda work around it by using an empty string instead of null to mean "present but no data", but for Integers its a little more difficult. decimalPlaces
has to be positive, so a -1 value could be a workaround there ... but -1 might be a valid min
value.
Update:
The solution to this is to make the POJO's with every field as Optional<>
. The fields default to null, then the setter methods are used to create a new Optional<>
object when JSON is sent. If object.getField() == null
then the field was not modified and the field was not present in the incoming JSON. If object.getField().isPresent() == false
then the field was modified and explicitly set to null. If object.getField().isPresent() == true
then the field has a new value to update.
This process is somewhat time consuming to implement, so not all the PUT
endpoints are implemented yet. Per @ctucker3 's request the following endpoints have this extra structure. Other endpoints will be implemented by request.
PUT /variables
PUT /traits
PUT /scales
PUT /methods
PUT /programs
Create a trait:
https://test-server.brapi.org/brapi/v2/variables
Then try to update it (notice change in scale decimal places, valid value min, valid value max):
Result:
The scale decimal places, valid value min, valid value max don't change to be null.