fix null queries over links to an indexed property

[ironage]

This was introduced in #3432.
The optimization made there is correct except when searching for null because we consider a null link along the relationship path to the property to be a match.

[jedelbo]

we consider a null link along the relationship path to the property to be a match

Is that so? It kind of surprises me. If you have a query like friend.buddy.pet == NULL then I would expects to get all objects that have a friend that has a buddy that does not have a pet. It should not include the friends that have no buddies.

[ironage]

This fix is only to make queries for null across links on indexed properties consistent with queries for null across links on non indexed properties. Additionally, it is only the optimized path that had a problem. Without this PR friend.buddy.pet == NULL would produce different results than NULL == friend.buddy.pet. Because we only optimize for constant on the right hand side.

I agree it is surprising behaviour, but it I think changing it would be considered breaking behaviour. There may be a strong argument to change the behaviour (I don't know the historical reasons why it is this way), but a counter argument is that if you have many links it may be tedious to write queries which do check for null along the link path. Users would have to transform friend.buddy.pet == NULL into friend == NULL || friend.buddy == NULL || friend.buddy.pet == NULL whereas today we assume this behaviour and if users want to opt out of this they can write friend.buddy != NULL && friend.buddy.pet == NULL. I'm not sure which behaviour is more intuitive actually, but having this greedy link behaviour seems somewhat easier to explain.

[nirinchev]

I think that Jørgen's interpretation is more intuitive. If we're concerned about the verbosity, we can introduce new syntax - ?. which will return a match if anything in the chain equals null - i.e. friend?.buddy?.pet == NULL. But I'd say that the current behavior is unexpected and if someone was relying on it, then they likely have a bug in their code.

[ironage]

We have tried to conform to NSPredicate perhaps that is the reason. @tgoyne do you know which behaviour Apple has chosen?

[tgoyne]

In NSPredicate, "a.b.c = nil" is equivalent to "a = nil OR a.b = nil OR a.b.c = nil". This is inherited from the obj-c semantics where the dot operator is what more modern languages have as ?..

[jedelbo]

Arguments accepted