I have long wanted something like this. However, it would need to be able to handle: 1) possible unique_together clauses 2) communicating clearly to the user what it tried to do and what went wrong when it errors
The thing that has made me wary of suggesting something like this is the fact that unless the designed carefully, will be less explicit than a piece of a python tool should be. On Monday, August 25, 2014, Benjamin Scherrey <proteus...@gmail.com> wrote: > Just want to run an idea by the list for a feature improvement for the > oft-used convenience functions get_or_create and update_or_create. I'll > just talk about get_or_create for now on but everything I saw going forward > applies to both. > > It's a common idiom to populate a dictionary and simply pass it straight > on to the function when creating or updating objects. While get_or_create > takes a named parameter, defaults, as the content to store/update and the > normal parameters are used for both search and content. The problem is that > quite often you just have a dictionary of content you want to throw into > the model table and don't want to separate it out into search content vs. > default content. If you don't separate it out you get a big nasty where > clause on the select that tries to compare every bit of content for the > item. > > For the most part this behavior is just a nuisance and probably > sub-optimal db query. However, with the new json data type it will actually > cause the code to break as you can't pass in a json structure as a search > value in a where clause. Your app will break. > > My proposal, which I've written in my own code, is to have get_or_create > automatically select the most appropriate data to use for the search clause > and then to make the rest "default" data to be applied to the found or > newly created object. It first tries to see if the primary key field is > present in the data structure. If that's not found then it goes through the > model fields and looks for any field designated as unique in the data > structure. The result is a cleaner and faster SQL request and a prevention > of the above mentioned error condition. If no primary key or unique field > is present in the data structure then behavior will continue as currently > implemented. > > Is this a change that would be welcome in the django project? If so I'd > be happy to create a pull request that implements this policy and > supporting unit test coverage. > > thanx, > > -- Ben > > -- > Chief Systems Architect Proteus Technologies <http://proteus-tech.com> > Chief Fan Biggest Fan Productions <http://biggestfan.net> > Personal blog where I am not your demographic > <http://notyourdemographic.com>. > > This email intended solely for those who have received it. If you have > received this email by accident - well lucky you!! > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com > <javascript:_e(%7B%7D,'cvml','django-users%2bunsubscr...@googlegroups.com');> > . > To post to this group, send email to django-users@googlegroups.com > <javascript:_e(%7B%7D,'cvml','django-users@googlegroups.com');>. > Visit this group at http://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/CAHN%3D9D7-RYgHe_a0uAKpr8mMYyvfY2CB%2BbLD6rcTSOPevwqdhQ%40mail.gmail.com > <https://groups.google.com/d/msgid/django-users/CAHN%3D9D7-RYgHe_a0uAKpr8mMYyvfY2CB%2BbLD6rcTSOPevwqdhQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- I am brief to respect your time. Pardon if I sound curt. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2By5TLbfA2ChiW0TMoVGCPHi6i%3DRD17HUtikzgMvsFcwKL-qww%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
