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
30199	get_or_create documentation encourages unsafe usage	Alex	Alex	"The documentation for QuerySet.get_or_create() (https://docs.djangoproject.com/en/2.1/ref/models/querysets/#get-or-create) buries the following caveat in an unhighlighted paragraph of text more than a page in:

> This method is atomic assuming correct usage, correct database configuration, and correct behavior of the underlying database. However, if uniqueness is not enforced at the database level for the kwargs used in a get_or_create call (see unique or unique_together), this method is prone to a race-condition which can result in multiple rows with the same parameters being inserted simultaneously.

In practice I have seen get_or_create() used with non-unique kwargs many times, so this caveat should come sooner in the documentation and be inside a ""Warning"" box.

The next paragraph of the documentation says:

> If you are using MySQL, be sure to use the READ COMMITTED isolation level rather than REPEATABLE READ (the default), otherwise you may see cases where get_or_create will raise an IntegrityError but the object won’t appear in a subsequent get() call.

This is dangerous and generally bad advice. By lowering the isolation level, you are trading off the occasional DoesNotExist during concurrent writes for subtle data integrity bugs, which is rarely an improvement. The trade-off should be presented but READ COMMITTED should not be recommended."	Cleanup/optimization	closed	Documentation	dev	Normal	fixed			Ready for checkin	1	0	0	0	0	0