Fixed a bug where == was used to compare a value with nil

[jechol]

Contributor checklist

• Bug fixes include regression tests
• Features include unit/acceptance tests

[zachdaniel]

So, this actually needs to be a bit more complex. We have to check if the identity considers nulls distinct, and if it does then we can do the is_nil() check, otherwise we cannot use that identity for this. Because there can be duplicates in that case.

[jechol]

I hadn't considered that case. The reason I became interested in this bug is that ever since filter_for_records was introduced, I kept encountering the message, Comparing values with nil will always return false. Use is_nil/1 instead. In: #{inspect(call)} in certain parts of my application. Please take that into account.

[zachdaniel]

I understand, but this fix will essentially have the same bug just without the warning. Do you have any resources without primary keys?

[jechol]

No, all my resources have primary keys.

[zachdaniel]

That represents a more serious issue. Primary keys aren't supposed to be able to be nil. So this code is very likely not working properly for you.

[zachdaniel]

Can you think of a way that you could end up passing records w/o their primary key into the data layer?

[jechol]

It looks like it was fixed by a311224, so I'm closing this PR.