id	summary	reporter	owner	description	type	status	component	version	severity	resolution	keywords	cc	stage	has_patch	needs_docs	needs_tests	needs_better_patch	easy	ui_ux
31242	RelatedManager Set Semantics vs. Behavior	Clayton Daley	nobody	"The `set` method is available on the many side of a 1:many or many:many.  The documentation clearly states that the method will ""Replace the set of related objects"".  Unfortunately, on the reverse side of a ForeignKey that is **not** nullable, this is not the actual behavior.  Instead, it only `add`s the submitted keys.  I consider this as a bug full stop as the method shouldn't be available if the implementation does not follow its semantics.

The limitation arises because `clear` and `remove` are not available for a non-nullable reverse FK (and this restriction is actually documented in both of those methods).  Unfortunately, the same limitation cascades to the `set` method without documentation or exception.

Documentation is a good start, but this seems like a core function that you wouldn't necessary test in an application so I'm going to try to make the stronger case for a breaking change at the first opportunity.  The long-run solution that aligns with the current implementation is to remove the `set` method from non-nullable reverse FKs (like `remove` and `clear`), forcing apps to actually use `add`.  Since I consider the current behavior a bug, this only affects bugged users (but could be a breaking change for some).  In practice, I'd throw an informative exception so users aren't confused by the sudden ""loss"" of (bugged) functionality."	Bug	closed	Database layer (models, ORM)	2.2	Normal	wontfix			Unreviewed	0	0	0	0	0	0