That is how it works now.
On Sat, Jul 26, 2014 at 6:38 AM, Mattias Linnap <[email protected]> wrote: > One way to make it work in presence of field lookups would be to demand > that the full values of mandatory fields must be present in the defaults > dictionary. > > For example: > Model.objects.get_or_create(name_iexact='hello', defaults={'name': > 'Hello', 'slug': 'foo'}) or > Model.objects.get_or_create(pub_date__month=12, defaults={'pub_date': > timezone.now().date()}) > > > On Tuesday, 10 June 2014 08:26:07 UTC+3, [email protected] wrote: >> >> I don't think this is possible to do generally. What would count__gt=1 or >> pub_date__month=12 do? >> >> On Friday, June 6, 2014 3:50:08 PM UTC-6, Patrick Bregman wrote: >>> >>> Hi all, >>> >>> First of, I'm new to this list so please tell me if there's something >>> that can be done better. It's the best way to learn for me ;) >>> >>> Recently I've been doing some reworking of an old (think Django 1.1 or >>> 1.2) webapp of mine into the latest and greatest of Django. In the process >>> I modified some models, and thought that *get_or_create* would be >>> perfect to replace boring try / except cases. Except that it didn't really >>> work as planned. I tried to do a *get_or_create(name__iexact=value, >>> defaults={'slug': slugify(value)})*. I expected this to be smart enough >>> to know that it should fill the field *name* based on the *name__iexact* >>> parameter. Apparently it isn't :) In this case you'd need to add a >>> definition for *name* to the *defaults* dict to get the value into the >>> newly created model. I'm not sure, but I personally think this shouldn't be >>> that hard to fix. It's basically checking (and removing) known field >>> lookups or simply everything after a double underscore, and using that as a >>> field name. Or at least, that's my view on it. >>> >>> The big question is: >>> 1. Is this behavior that exotic that I'm the first one to notice, or did >>> I do a wrong search on Google? >>> 2. Would this indeed be as easy (or comparably easy) as I think? >>> 3. Is this behavior we actually want in Django? >>> >>> If the answer to 2 and 3 are yes, I'll look into giving it a try to >>> making a patch for this myself. >>> >>> Regards, >>> Patrick Bregman >>> >> -- > You received this message because you are subscribed to a topic in the > Google Groups "Django developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/EbLRpYB_1WI/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/dbe4723f-2a8c-4a5c-94cd-be264c1198ef%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/dbe4723f-2a8c-4a5c-94cd-be264c1198ef%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACPudh2XpFvA%3Dx9S5G1HUbr3wu3pCQpLdYfaFX8dn00cYYcsQA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
