Hi Andrew,
Thanx for the feedback. I'm glad to hear you've independently
encountered the same issue as I have.
1) unique_together would not be difficult to handle but I also don't think
it's necessarily an absolute requirement. The default behavior would
ultimately take advantage of a unique_together enforcement by happenstance
if a better method isn't discovered.
2) What would be the mechanism by which you'd want to have this information
communicated? I can't really think of anything that doesn't break existing
apis beyond using django.db.connections['default'].queries to see what the
actual produced SQL was.
As far as "what went wrong when it errors" - what kind of error condition
do you anticipate? If we find that the data passed in happens to apply to a
unique not-null field then we'll explicitly search by it. If that search
fails then your normal search would have failed as well. If no such fields
are found in the passed data then the normal behavior follows. Is there
something you have in mind that I'm missing?
I completely agree with your desire to be explicit. I don't think that this
proposal changes any api semantics whatsoever actually. If the developer
actually passes an explicit 'default' parameter then the normal behavior
should ensue because the user has already made his intentions of what data
is intended for search. I really view it as an optimization and, in fact,
the existing behavior without a 'default' parameter actually goes against
what mine and, I anticipate, others mental models of what kind of behavior
they would have expected.
-- Ben
On Mon, Aug 25, 2014 at 8:37 PM, Andrew Farrell <armorsmit...@gmail.com>
wrote:
> 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.
>> 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/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
> <https://groups.google.com/d/msgid/django-users/CA%2By5TLbfA2ChiW0TMoVGCPHi6i%3DRD17HUtikzgMvsFcwKL-qww%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
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.
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/CAHN%3D9D7sxZsthX5-TtwTuyTb8z9vVDf-raaxf%3Dyw%2BkVN57i7Kg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
