How to handle nulls in ordering

[szarnyasg]

Currently, our engine throws NPE-style errors (e.g. MatchError: null) when it needs to compare nulls.

ORDER BY x.name places nulls after variables with actual values (implying that null > some is true).

Note that null == null is true in JVM-based languages but it is null in openCypher.

See also the related CIP at https://github.com/opencypher/openCypher/blob/8fa5658e433060a208971845a2b301d140461535/cip/1.accepted/CIP2016-06-14-Define-comparability-and-equality-as-well-as-orderability-and-equivalence.adoc#missing-null

[jmarton]

A related aspect is null values in grouping keys, see also in the CIP cited above: https://github.com/opencypher/openCypher/blob/8fa5658e433060a208971845a2b301d140461535/cip/1.accepted/CIP2016-06-14-Define-comparability-and-equality-as-well-as-orderability-and-equivalence.adoc#311-the-meaning-of-null

Probably we should think of a comprehensive solution. How much overhead would it cause if we were using Option[Any] inside the engine, and only the production node would unpack them: Some(x) => x and None => null

[szarnyasg]

31814c6 in not a nice solution, but it has effectively zero overhead.

[szarnyasg]

I reverted b1f3a2e as the original tests now working. The current solution is good enough, so I'm closing this issue for now.