Hello,
In java, when I “deepSave” a user on which I assign “null” to a multiple choice field, the null value is not persisted while other fields are well updated.
Do you have an idea please ?
Hello @Seb777!
Thank you for your question!
Could you please tell me if you’re receiving any error messages or exceptions when attempting to save the null value?
Also, is it possible that the multiple choice field has a “Not Null (Required)” constraint that’s preventing the null value from being persisted? It’s worth checking if this is the case.
Any additional information you can provide would be helpful in identifying the root cause of the issue.
Thank you and looking forward to hearing back from you.
Regards,
Alexander
Hello @Alexander_Pavelko
Sorry, it’s not a deepSave. Here is the code that does not work as expected :
Users users = Backendless.Data.of(Users.class).findById("blablabla");
users.setMultipleChoice(null);
users.setName("new name");
UnitOfWork unitOfWork = new UnitOfWork();
unitOfWork.update(users);
UnitOfWorkResult result = unitOfWork.execute();
if (!result.isSuccess()){
throw new RuntimeException(result.getError().getMessage());
}
The name is updated but not the multiple choice field.
When I use the following code, it works as expected :
Users users = Backendless.Data.of(Users.class).findById("blablabla");
users.setMultipleChoice(null);
users.setName("new name");
Backendless.Data.of(Users.class).deepSave(users);
Why is it not working when I update the user in transaction ?
Thank you for your help 
Can you please clarify something for me?
When you update a user in the transaction and pass a value that is not null in setMultipleChoice, does it get set, or is the situation the same as with null?
Regards,
Alexander
When I set a value that is not null (in the transaction), the value is well updated.
Regards,
@Seb777, we have been able to reproduce the issue, and internal trouble ticket was created for that - BKNDLSS-31791 . As soon as the issue is fixed, we will let you know.
Regards,
Marina
1 Like
Hi @Seb777,
We have found that your code to update the multiple choice data type values is incorrect. Please use the fillowing code to update values you need in the multiple choice column:
Map users = Backendless.Data.of("Users").findById("blablabla");
users.put("multipleChoice", null);
users.put("name", "new name");
UnitOfWork unitOfWork = new UnitOfWork();
unitOfWork.update("Users", users);
UnitOfWorkResult result = unitOfWork.execute();
if (!result.isSuccess()){
throw new RuntimeException(result.getError().getMessage());
}
Regards,
Marina
Hi @Marina.Kan
Thank you for the answer.
So the only difference is to use the “Java Map” approach instead of “Custom Class” ?
To me it looks more like a workaround than a solution. If Backendless offers two approaches (“Java Map” and “Custom Class”) there is no reason for one to support the update (of a null value) of a multiple choice in a transaction and not the other.
Currently the “Custom Class” approach already makes it possible to update a multiple choice in a transaction except when it comes to putting the value null. Sounds more like a bug to me.
Hi @Seb777
This is the expected behavior of the server which does not allow setting ‘null’ values to custom user columns (not only those with multiple choice type). The reason is that the server cannot know how you obtained your “users” object.
Imagine that you obtained it in the following way:
Users users = Backendless.Data.of(Users.class).findById("blablabla", DataQueryBuilder.create().addProperties("objectId"));
In this case, the users object will only have the ‘objectId’ field with the value ‘blablabla’, and all other fields of the class will have ‘null’ values. Then, you may do the following:
users.setMultipleChoice(null);
users.setName("new name");
by setting values for the ‘multipleChoice’ and ‘name’ fields, but all other fields will remain ‘null’, while in the database they may have real values that you simply did not request when you initially obtained your users object. And now, when you try to use:
UnitOfWork unitOfWork = new UnitOfWork();
unitOfWork.update(users);
UnitOfWorkResult result = unitOfWork.execute();
if the server allowed setting ‘null’ values, then the data of the unrequested fields would have been updated to null and would have been lost.
Conclusion:
- With the “Custom Class” approach, the server cannot accurately determine whether you intentionally set a ‘null’ value for a field or simply did not request it when retrieving your users object, so with the “Custom Class” approach, the server rejects all fields with null values and only updates fields with actual values.
- With the “Java Map” approach, the server is confident that only the fields you wanted to update with the values you specified (even if it’s null) will be updated.
Regards,
Viktor
