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
27070	Support for `Q` objects in `get_or_create` and `update_or_create`	Flavio Curella	nobody	"Since `Q` objects can be used to `.filter` queryset,I think it would make sense to leverage their functionality when looking up for objects in  `get_or_create` or `update_or_create`.

There currently isn't any way to use `Q` objects when checking for existence in  `get_or_create` and `update_or_create`. There are two main reasons for that:

1. The signature of these methods prevents the usage of unnamed arguments
2. When `OR`ing `Q` objects, if the lookup fails, and those fields are not specified in `defaults`, we have undefined values for the object that we need to create.

We could address 1. by adding a keyword argument (let's call it `query` for now), so that the signature would be `get_or_create(defaults=None, query=None, **kwargs)`. It could then be used in this way:

{{{
obj, created = Person.objects.get_or_create(
    query=Q(first_name=""George"") | Q(first_name='Bruce'),
    defaults={""last_name"": ""Harrison""},
)
}}}

Re 2., we have two options:

2a. Leave the ambiguous fields undefined (but this would be inconsistent with the 'non-`query`' behavior).
2b. Force the user to specify the field in `defaults` by raising some exception. Not happy about duplicating data in `query` and in `defaults`
"	New feature	closed	Database layer (models, ORM)	dev	Normal	invalid			Someday/Maybe	0	0	0	0	0	0