The implementations of PartialEq for Many and ForeignKey currently have no tests that cover them properly. The tests string_pk, fkey_match & rustval requires that a ForeignKey or Many returns true during a comparison of a stored object and its fetched equivalent. i.e. No test currently depends on eq returning false.
The implementation for ForeignKey only checks that the key value is identical.
Now I understand why this is the current implementation. But it is worth thinking about whether it is correct, as it can be quite surprising. If retained like this, it should be documented very prominently.
The Many implementation similar checks only that they target item_table and owner are the same - the content could wildly differ. This one is worse, because .add or .remove could have been invoked, making the two objects very-very different but they would still say they are equivalent.
The implementations of
PartialEq
forMany
andForeignKey
currently have no tests that cover them properly. The testsstring_pk
,fkey_match
&rustval
requires that aForeignKey
orMany
returnstrue
during a comparison of a stored object and its fetched equivalent. i.e. No test currently depends oneq
returningfalse
.The implementation for
ForeignKey
only checks that the key value is identical.Consider this, which passes
Now I understand why this is the current implementation. But it is worth thinking about whether it is correct, as it can be quite surprising. If retained like this, it should be documented very prominently.
The
Many
implementation similar checks only that they targetitem_table
andowner
are the same - the content could wildly differ. This one is worse, because.add
or.remove
could have been invoked, making the two objects very-very different but they would still say they are equivalent.