Determine if __cmp__ in Package model is safe with mongoengine
There is a scary todo and some discussion about it during review. This overrides the mongoengine cmp which may have unintentional side effects. For example querysets and caching in mongoengine may rely on the builtin cmp definition behavior for core functionality.
I think the key question to answer here is: "Is overriding the mongoengine the cmp safe?"
Come up with an answer to that question, remove the scary DANGER note, and adjust the code so that it's safe.
Updated by bmbouter about 7 years ago
I've determined this is safe. I'm making a PR removing the scary TODO, but I'm writing what I've learned here.
__neq__(). It does not provide other rich comparison methods (ie:
__ge__(), ...). It also does not provide
__cmp__(). Python Data Model docs state that since Python 2.1 "[
__cmp__() is called] by comparison operations if rich comparison (see above) is not defined."  This behavior ensures that for == and != operations which mongoengine expects to have its
Document.__neq__() will be used as expected.
Also since mongoengine doesn't provide rich comparison operators we can be reasonably sure that it's not relying on the mostly non-sense comparison provided by the built in object.__lt__ implementation and other default rich comparison operators. Since mongoengine couldn't make meaningful use of these defaults, Pulp is free to define the comparison with
__cmp__() as necessary.
One area of concern comes from the mongoengine's
__neq__() being called instead of the
__cmp__() when Pulp is comparing the equality or inequality of two units. The
__neq__() of mongoengine is an ObjectId comparison of the _id fields. The
__cmp__() Pulp has historically used would be a tuple comparison of (epoch, version, release) which could cause things that were considered equal to no longer being equal. In this area I think we should just bugfix as problems come up. If two units are not the same record in the DB, the equality comparison of them should not say they are so this new behavior is more correct.
Note that for Python 3 compatibility we will need to replace
__cmp__() usage with the
__ge__(). When we do that we should not implement
__neq__() because we could be affecting mongoengine internal behaviors by doing so.
For fun, here  is an interesting example of the motivation for rich operators which uses RPM tracking as the example.