keepNull on updateDocument not working any more?

[miguel-porto]

EDIT: the original question is wrong, but see the comment...
Hi, I'm not sure if this is a bug or if I'm doing something wrong. It seems that the keepNull option of the updateDocument() has no effect now - the uninitialized fields of my object are always removed, no matter the value of keepNull. My object is something like

public class TaxEnt extends NamedDBNode implements ResultItem {
	protected Integer rank;
	protected String annotation;
	protected String sensu;
	protected String author;
...
}

Then I make newTaxEnt whose rank field is null, and update it like
database.collection(node.getColletion()).updateDocument(node.getDBKey(), newTaxEnt, new DocumentUpdateOptions().keepNull(false))
The rank field is always removed, no matter if I use keepNull(false) or keepNull(true)... this also happens with the Strings.
And I know it was there, as returning the old object yields
{"oldRev":"_UCCVtCO---","oldDocument":{"rank":200,"annotation":"","sensu":"","author":"ccc","current":true,"isSpeciesOrInf":true,"name":"Aaa bbtaa","_id":"taxent/1489743447570","_key":"1489743447570"},"key":"1489743447570","id":"taxent/1489743447570","rev":"_UCCXXMq---"}

Let me know if you can you replicate this issue. This piece of code was working before I migrated to the new driver. My ArangoDB is 3.1.0.
Best,
Miguel

[miguel-porto]

Hmmm. I think I understand, this operation (changing the value of one field without touching the others) is not possible with updateDocument (as per the API docs) (but it was possible before). Is there any solution for changing only one field of a document (besides the AQL UPDATE ... WITH {...} )?

[mvollmary]

Hi Miguel,

the functionality behind updateDocument in the driver was a topic where I struggled with myself.

In the old version of the driver when you set keepNull to true. The members with null values of your pojo were not transfered to the server and only non-null values were updated.
With keepNull to false all members were transfered to the server and the corresponding fields in the stored document of those who were null in your pojo were deleted. But this is not what the server functionality of update document with keepNull means.

I missed the possibility of setting a value to null without removing the field from the stored document. But this is - in my opinion - what updateDocument stands for.

So I decided to change this. Now every member of your pojo - no matter which value it has or which value keepNull has - is transfered to the server. If keepNull is true every fields value in the stored document - where the corresponding member in your pojo is null - is set to null. If keepNull is false, these fields are deleted from the stored document.

With this functionality we get the possibility to set fields in stored documents to null. Now - if we only want to change some fields of a document - we have to create a document in the client with only the fields to be updated.

To do so, we have 5 different options:

1. BaseDocument
   BaseDocument value = new BaseDocument():
value.addAttribute("rank", 1);
2. Map
   Map<String, Object> value = new MapBuilder().put("rank", 1).get();
3. VelocyPack
   VPackSlice value = new VPackBuilder().add(ValueType.OBJECT).add("rank", 1).close().slice();
4. plain Json
   String value = "{\"rank\":1}";
5. serialize your pojo before call updateDocument
   This could be the most comfortable option for you. The classes ArangoDB, ArangoDatabase, ArangoCollection and some others have a util() method. With that method you can get the ArangoUtil with which you can serialize/deserialze POJOs, Json to/from VelocyPack. Here we can decide to not serialize null values from our pojo. So we serialize our pojo to VelocyPack wihtout null values before calling updateDocument.
   VelocyPack value = arangoDB.util().serialize(origValue, false);

Use one of these options with updateDocument(key, value) and use keepNull only to delete or keep field with nullValues.

This should make all your cases possible, let me know if not. It would also be great if you give us feedback on what you think.

Best,
Mark

[miguel-porto]

Hello Mark,
Thanks for the detailed reply. I do understand the situation. In my data model, having a field set to null or not having the field at all, means the same, but I understand that this is not the general case. I will try one of those simpler options with Maps or plain JSON.
However, I think that creating an option in DocumentUpdateOptions like ignoreNull would be advantageous. It seems to me that you would only need to change this line with the value of that option, to achieve the functionality of optionally not copying the null values in the pojo, right? The only downside is that users might get confused with two options "keepNull" and "ignoreNull"...
Cheers, and thanks for explaining!
Miguel

[mvollmary]

Hi Miguel,
Thanks for your feedback. I implemented an additional option called serializeNull in DocumentUpdateOptions. It is included in the version 4.1.1 which is already released.

Best,
Mark

[miguel-porto]

Thanks! That's a better name for the option indeed.
Best,
Miguel

[hepworthjd]

Hello,

I think there is an inconsistency with updateDocument and updateDocuments with regard to this - looking at the source for the former I see:

		request.setBody(
			util().serialize(values, new ArangoSerializer.Options().serializeNullValues(false).stringAsJson(true)));

compared to the latter:

		request.setBody(util().serialize(value, new ArangoSerializer.Options()
				.serializeNullValues(params.getSerializeNull() == null || params.getSerializeNull())));

This means I have to use multiple calls to updateDocument if I want null values removed

Thanks
Julian

[robross0606]

I think there may still be a problem with this when doing mergeObjects as false. Because you're now transferring all the null to the server, it seems to be persisting null values even if keepNull is also false.

[rashtao]

@robross0606 since the information in this ticket is partially outdated or refers to old releases, please open an new issue providing a code snippet to reproduce the problem from the current latest version, so that we can isolate and address the issue faster.