Executing PatchHandle against non-existing Document does not throw an Exception about java-client-api

[rjrudin]

Thanks for the tests @Zipunrar , I'm trying them out now.

[rjrudin]

@Zipunrar Thanks again for the test, made debugging very easy.

I haven't identified why yet, but "unknown" seems to be a special case. If I change that to "unknown.xml" or even "unknownn", I get the expected 404 and ResourceNotFoundException from ML. But the specific value "unknown" results in a 204 No Content being returned.

Can you try your test with "unknown.xml" and "unknownn" (or any word besides "unknown") as the URI? Curious if you get the same results.

[Zipunrar]

Hi @rjrudin ,

very interesting. Never thought the URI could lead to such strange behavior. I tried some different values and get other results depending on the value of the URI.

• "unknown", "unknown.xml", "foobar", "unknownn" produces failed tests for both property and collection patching
• "foo/bar.xml", "check", "simple/test/with/random/uri.json" however does only fail for the property patch not for the collection or document patch
• I didn't find values to let only the collection patching fail
• In all cases the patching document test never fails and the expected exception will be thrown

[rjrudin]

Revisiting this - for patching document properties, I verified that the underlying server functions - xdmp:document-set-properties and xdmp:document-add-properties - do not throw an error if the URI is not found. So the third test that invokes addPropertyValue is behaving correctly.

However, I'm able to produce the same behavior in qconsole - i.e. xdmp:document-set-collections will fail for some URIs but not throw an error for other URIs. If I run a "clear" operation on the database, then the function will fail for all URIs. So it appears to be a server issue where URIs perhaps associated with deleted documents do not always result in an error being thrown. Will investigate further - but I don't think this has anything to do with the Java Client or the REST API.

Will leave this open until I isolate the server issue.

[rjrudin]

@Zipunrar I think I know the explanation. As noted above, performing any "properties" operations on a URI will succeed and results in a properties fragment for the URI being created - even though there's not a document for that URI. So if you start with an empty database, you still won't see any documents in qconsole, but you will see a fragment count of 1 in the Admin UI for that database.

Once the URI is associated with a properties fragment, all metadata operations will succeed on that URI. If you clear the database, that will delete the properties fragment, and then all metadata operations (including PATCH requests) will throw an error as expected.

With your test, if you were to run it twice, the test that adds a collection would not throw an error because the test that adds a property would have resulted in the URI being created with a properties fragment associated with it.

Thus, I do not believe there is a bug here - the behavior with the Java Client and REST API is consistent with how the server functions work when a URI is involved that only has a properties fragment associated with it.