If I understand correctly, LEFT JOIN is automatically chosen when
ForeignKey(null=True) otherwise it will be INNER JOIN?
My ProfileRequisites.profile ForeignKey is not nullable yet I need to use
LEFT JOIN in this query so I have profiles and ProfileRequisites in the
same list. Profiles are always retrieved while ProfileRequisites only if
these are available (LEFT):
class ProfileRequisites(models.Model):
profile = models.ForeignKey(Profile, related_name='requisites')
requisites_type = models.ForeignKey(
ContentType, null=True, related_name='related_requisites',
verbose_name='Тип реквизитов'
)
requisites_id = models.PositiveIntegerField(verbose_name='Ссылка на
реквизиты')
requisites_object = GenericForeignKey('requisites_type', 'requisites_id')
is_preferred_withdrawal = models.NullBooleanField(default=None,
verbose_name='Предпочтительный способ вывода')
On Friday, April 21, 2017 at 7:55:31 PM UTC+3, Adam Johnson wrote:
>
> It depends upon whether the foreignkey/onetoonefield is nullable.
>
> On 21 April 2017 at 17:16, Dmitriy Sintsov <[email protected]
> <javascript:>> wrote:
>
>> How can I chose whether select_related() will use LEFT JOIN or INNER
>> JOIN? There are two joins, one is LEFT another is INNER one.
>>
>> On Friday, April 21, 2017 at 1:40:47 PM UTC+3, Adam Johnson wrote:
>>>
>>> Joining two tables like that on one-to-one relations can be easily
>>> achieved with select_related
>>> <https://docs.djangoproject.com/en/1.11/ref/models/querysets/#select-related>
>>> .
>>>
>>> On 21 April 2017 at 09:47, Dmitriy Sintsov <[email protected]> wrote:
>>>
>>>> I know that it does not work in the general case, but still having
>>>> orthogonal processing of RAW queries with the same filter() / order_by()
>>>> calls matches Django's DRY philosophy.
>>>> Raw queries which has hardcoded WHERE and ORDER BY statements will
>>>> simply raise an error when another WHERE / ORDER BY statement is added by
>>>> filter() / order_by().
>>>> But there is no point to specify WHERE manually when there is filter()
>>>> available and such error brings no direct harm.
>>>> I implemented it mostly to use in paginated ListView-like CBVs with
>>>> LEFT JOIN. Here is the example of real query from private project:
>>>>
>>>> 'SELECT isp_finances_profilerequisites.*, '
>>>> 'isp_user_profile.user_id, isp_user_profile.last_name,
>>>> isp_user_profile.first_name, isp_user_profile.is_verified,
>>>> isp_user_profile.inn '
>>>> 'FROM isp_user_profile '
>>>> 'LEFT JOIN isp_finances_profilerequisites '
>>>> 'ON isp_finances_profilerequisites.profile_id = isp_user_profile.user_id '
>>>> 'JOIN auth_user '
>>>> 'ON auth_user.id = isp_user_profile.user_id '
>>>>
>>>>
>>>> Is such RAW query (with working pagination and sorting) possible to
>>>> convert to model manager QuerySet query?
>>>>
>>>> On Friday, April 21, 2017 at 1:02:40 AM UTC+3, Adam Johnson wrote:
>>>>>
>>>>> I'm worried this doesn't work in the general case, as there are a lot
>>>>> of different query formats one can write with raw SQL, such as UNION, SQL
>>>>> variables, or other database specific formats. You have a lot of code
>>>>> there, but from what I can tell the code is simply setting up the
>>>>> RawSqlCompiler which adds WHERE etc. after the raw SQL, ignoring the fact
>>>>> that there could already be a WHERE in it - am I right?
>>>>>
>>>>> Also - what do you find raw queries being needed for? In general the
>>>>> ORM is very capable these days and the general development focus on it is
>>>>> to make it cover even more of SQL's capabilities.
>>>>>
>>>>> On 20 April 2017 at 20:36, Dmitriy Sintsov <[email protected]> wrote:
>>>>>
>>>>>> Hi!
>>>>>> I implemented FilteredRawQuerySet which supports filter() and
>>>>>> order_by() like model manager QuerySet.
>>>>>>
>>>>>> https://code.djangoproject.com/ticket/28087
>>>>>>
>>>>>> https://github.com/Dmitri-Sintsov/django-jinja-knockout/blob/master/django_jinja_knockout/query.py
>>>>>>
>>>>>> Internally it contains RawQuerySet and QuerySet for the target model.
>>>>>>
>>>>>> SELECT part of the query is borrowed from RawQuerySet, while WHERE
>>>>>> and ORDER BY statements are generated via QuerySet query.
>>>>>>
>>>>>> This feature is useful when the code uses programmatically generated
>>>>>> arguments of filter() / order_by(), for example in class-based ListView
>>>>>> with custom filtering and / or sorting.
>>>>>>
>>>>>> Is such feature worth to be included to Django core?
>>>>>>
>>>>>> I could just continue to use my own implementation (probably
>>>>>> imperfect) however I am worrying about possible query generation code
>>>>>> changes that could make my module incompatible in the future.
>>>>>>
>>>>>> In case such queryset would be included to Django code, there are
>>>>>> much more chances that the code which uses it would not break when
>>>>>> updating
>>>>>> to newer Django version.
>>>>>>
>>>>>> Dmitriy
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers
>>>>>> .
>>>>>> To view this discussion on the web visit
>>>>>> https://groups.google.com/d/msgid/django-developers/a20e043e-aec8-4806-9e6b-c5c669361c44%40googlegroups.com
>>>>>>
>>>>>> <https://groups.google.com/d/msgid/django-developers/a20e043e-aec8-4806-9e6b-c5c669361c44%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Adam
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/django-developers/08e7fa46-8aa1-4e92-bb70-9990abfc0e4c%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/django-developers/08e7fa46-8aa1-4e92-bb70-9990abfc0e4c%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>>
>>>
>>> --
>>> Adam
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers (Contributions to Django itself)" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> To post to this group, send email to [email protected]
>> <javascript:>.
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/4e96eb6a-3c22-472d-a80e-2f22ad3f49b9%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/django-developers/4e96eb6a-3c22-472d-a80e-2f22ad3f49b9%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Adam
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/f83009c0-047d-4114-bc12-d7260cc3e36f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
