Java getAllDocumentsByKey / getAllEntriesByKey Problem With Doubles

I try to avoid using the word “bug” too freely, because those who live by the word “bug” may die by the word “bug”! After all, we’re software developers whose own software may include bugs. Use the word freely and we can’t complain when others also do.

But a little while ago I was battling a strange problem which I’ve been able to isolate. I was using getAllDocumentsByKey, passing a Vector<Object> comprising a String, a Double and another Double. (To minimise the number of views in the database, I was reusing an existing view). The second parameter, exactMatch, was set to true. There were entries that should have been found, but the code was not finding them. The same happened regardless of whether the view was categorised or just sorted, regardless of using getAllDocumentsByKey or getAllEntriesByKey, and also failed on a view which didn’t have the first String column. To confirm the symptoms exactly, I managed to reproduce everything in a basic database, which is attached.

A number column in a Notes View has a value that in Java is a Double. This I was able to confirm with the Java agent “(Check Data Types)”. It shows the same data types – java.lang.String, java.lang.Double, java.lang.Double – in both the Vector and a sample view. The agent “(Lookup All Keys Check)” runs the getAllDocumentsByKey and getAllEntriesByKey runs the checks, showing it works looking for one Double column but not two.

Finally, I stripped it down to testing some views with two sorted columns, Year and WeekNo. In one test I tried setting @Text on the first column (so Vector was String,Double). In the second test I tried setting @Text on the second column (so Vector was Double,String). I tried both sets of lookups with WeekNo column first and Year column first. I also tried getAllDocumentsByKey and getAllEntriesByKey. So all scenarios.

The results were consistent: String,Double worked in all cases and returned the correct number of documents / entries; Double,String returned nothing. I also tried on 9.0.1, 9.0 and 8.5.3.

The workaround was to create a new view and avoid using number columns. But it’s an unexpected behaviour and one that’s not consistent with LotusScript. Of course, it happens not only in Java agents, but also Java classes used for XPages as well as Server-Side JavaScript (which just uses the underlying Java methods).

The good news is that IBM are aiming for a fix in 9.0.2. Thanks to Paul Hannan for picking this up and following it through. The SPR number, for those interested, is PHAN-9F7M76.

VectorCheck Database