1
votes

I have a need to execute end-user-composed, complex AQL filter expressions against collections with highly variable document structures. These filter expressions may contain range tests that cross zero, such as "doc.x < 10", but in these cases, documents that do not have the field 'x' defined will be returned as results due to NULL being interpreted as 0 by ArangoDB. This can be avoided by writing "doc.x != NULL && doc.x < 10"; however, this results in extra complexity especially when the filter expressions are complex to begin with.

Oddly, the ==, >, >= operators do not convert NULL values - only the <, <=, and != operators. Perhaps this is a bug (using ver 3.3.2)?

This behavior will likely result in user confusion/frustration at the very least. So, before I write my own query pre-processor to work-around this, I was curious if there is a way to disable this default NULL AQL behavior (for numeric expressions)?

Thanks!

2

2 Answers

1
votes

From the docs:

0 == null                 // false

which implies the same behavior for other comparison operators. So yeah, seems like a bug. Very weird that >= works but not <=, have you tested it with negative values as well, i.e. does NULL >= -1 return false?

If yes, then replacing doc.x < value with !(doc.x >= value) should work.

(Edit: Nevermind. This doesn't distinguish between doc.x == NULL and doc.x < value.)

If not, you will have to add null checks, although i'd be surprised if you notice a significant performance bump because of that.

1
votes

I contacted the ArangoDB devs and it turns out this behavior is working-as-designed. The current documentation is actually clear, I just hadn't looked at it in a while. The work-around is simply to add "doc.x != null" terms wherever they are needed, but for our particular use case this is a bit of a showstopper.