Неужели SQLite3 не поддерживает запросы с двойным (вложенным) INNER JOIN?

Спасибо! Вот до конструкции **_id__id не додумался!

Неужели SQLite3 не поддерживает запросы с двойным (вложенным) INNER JOIN?

winordie: там нет примера что бы втаскивать поля сразу из трех таблиц. Из любых двух таблиц в связке многое-ко-многим я, вроде, научился поля вытаскивать.

qs1 = TAB2.objects.filter( TAB1__id=1)

Когда запрашиваю поля из таблицы связей -- ругается, что таких полей нет.

Неужели SQLite3 не поддерживает запросы с двойным (вложенным) INNER JOIN?

Спасибо! Да, действительно так сработало. Получается, что не работают вложенные INNER JOIN. Странно, почему?

Давным-давно использовал базы MS Access... Там конструктор строил именно вложенные INNER JOIN для связей многое-ко-многим. Позже я пытался разобраться почему (для меня было проще строить вложенные SELECT вместо INNER JOIN). Оказалось, что вложенные INNER JOIN кушают меньше памяти и потому быстрее (как-то там к таблицам в GROUP BY суммирование применяется последовательно и они не захапывают ресурс для хранения больших промежуточный группировок). Так и повелось! Хотя вложенные INNER JOIN писать руками намного сложнее чем обычные.

Где быстрее сортировка в python/django вычисляемых SQL-полей?.. Через models или прямыми SQL-запросами?

Нет. Вопрос именно в использовании ORM-models или писать raw-запросы прям в SQL и не надеяться, что ORM что-то путевое сотворить.

Кстати, вопрос уже решен. Даже простейшие запросы с GROUP BY напрямую писать оказалось эффективнее чем через ORM (см. комментарии и код к вопросу toster.ru/q/150937).

Как в Django через ORM сделать SQL-запрос с INNER JOIN?

Anton Kuzmichev:
Гипотеза не подтвердилась. INNER JOIN и OUTER JOIN выполняются с одинаковой скоростью. Очевидно, проблема в чем-то другом. В реале у меня в TAB2 одна ссылка на саму себя (отношение записей родитель-потомок внутри одной таблице). Т.к. ORM строит SELECT по всем полям, и после еще по этим полям нужно GROUP BY то наверное вот эта ссылка саму-на себя и тормозит (хотя, вообще-то кажется это бред). В общем, оставлю raw запрос.

Как в Django через ORM сделать SQL-запрос с INNER JOIN?

Anton Kuzmichev:
Что выяснилось. Вместо того, чтобы сформировать запрос который кажется простым и очевидным:

p = TAB2.objects.raw(
    '''SELECT  TAB2.option, Count(TAB1.id) AS num1
       FROM TAB1 INNER JOIN TAB2 ON TAB1.Link = TAB2.id
       GROUP BY TAB2.option
       ORDER BY Count(TAB1.id) DESC;
    ''')

ORM превращает выражение:

TAB2.objects.annotate(num1=Count('TAB2')).order_by('-num1')

с запрос:

p = TAB2.objects.raw(
    '''SELECT TAB2.id, TAB2.option, COUNT(TAB1.id) AS num1
       FROM   TAB2
          LEFT OUTER JOIN TAB1
          ON ( TAB2.id = TAB1.Link )
       GROUP BY TAB2.id, TAB2.option
       ORDER BY num1 DESC;
    ''')

И этот запрос медленнее в 500 раз. Я, конечно, не настоящий сварщик, но из прошлой жизни программирования мне кажется что это из-за реализации OUTER JOIN в SQLite3... похоже он "перемножает" таблицы, а суммарную таблицу 100000x5000 записей обрабатывать реально дольше чем просто 100000 записей получаемый при INNER JOIN. Не понятно почему ORM пишет OUTER JOIN :(

Как в Django через ORM сделать SQL-запрос с INNER JOIN?

Anton Kuzmichev: Спасибо! Все получилось! Время выполнения 0.87...1.28 секунды!

Осталось, все таки разобраться как заставить ORM делать такое без raw-запросов.

Как в Django через ORM сделать SQL-запрос с INNER JOIN?

Anton Kuzmichev:
Поставил консольное приложение SQLite3. Написал в нем запрос с GROUP BY (на самом деле у меня несколько сложнее база чем в примере выше). Запрос выполняется "мухой"! Так что, получается, не в SQLite3 проблема, а в ORM. Теперь разобраться как этот запрос из Django выполнить. Почему-то через raw не получается.

p = TAB2.objects.raw(
    '''SELECT  TAB2.option, Count(TAB1.id) AS CountObj
       FROM TAB1 INNER JOIN TAB2 ON TAB1.Link = TAB2.id
       GROUP BY TAB2.option
       ORDER BY Count(TAB1.id) DESC;
    ''')

Пишет: Raw query must include the primary key
Похоже это из-за того что обращаюсь: TAB2.objects.raw()
К сожалению в мануалах нет примеров как через модель писать raw-запрос к нескольким таблицам (djbook.ru/rel1.4/topics/db/sql.html). А писать в обход моделей как-то не очень. В мануале рекомендуют так делать только если надо получать доступ к несколькими СУБД одновременно.

Так что остается или разобраться как писать правильный GROUP BY через ORM (в интернетах за это неумение ругают ORM и говорят что он хорошо этого делать не умеет), или разобраться как raw-запрос с GROUP BY вызвать. :(

Как в Django через ORM сделать SQL-запрос с INNER JOIN?

Т.к. я не настоящий сварщик, то для меня SQLite3 хороша тем, что очень просто сделать backup перед любым экспериментом. Чтобы данные не потерять (уж больно долго их парсил с сайта одного министерства).

Я не могу понять почему у меня все так медленно. В прошлой жизни программиста (лет 15 назад, на тех еще машинах) такие данные летали! При том, что SQL-запросы шли в Access через ODBC... Access тоже все данные (и таблицы, и вьюшки, и кеш-запросы, и параметры репликаций) хранит в одном фале... т.е. по сути не должен SQLite3 от него существенно отличаться по производительности.

Мне кажется, что я что-то делаю не так. Но не могу понять, что... :(

Как в Django через ORM сделать SQL-запрос с INNER JOIN?

Anton Kuzmichev: :( Я надеялся перейти на серьезную базу поближе к продакшену. Не ожидал что такой несерьезный запрос для SQLite3 окажется тяжелым. Попробую написать raw-запрос в обход ORM: djbook.ru/rel1.4/topics/db/sql.html

И зачем я с этим ORM связался? :(

Как в Django через ORM сделать SQL-запрос с INNER JOIN?

Изучил, спасибо, все сделал как советуют. Обескуражен:

1. Если делаю все ручками, т.е. выгружаю данные в словарь и там перебором поддсчитываю элементы время выполнения -- 48 секунд:
2. Когда делаю выгрузку TAB2 и по циклу спрашиваю через SQL сколько записей в TAB1 удовлетворяющих условию TAB1.Link = TAB2.id -- 751 секекунд.
3. Когда делаю через агрегацию:

TAB2.objects.annotate(num_in_TAB2=Count('TAB2')).order_by('-num_in_TAB2')

время выполнения -- 827 секунд.

СУБД -- SQLite3
в TAB1 чуть менее 120 тыс. записей
а ТАB2 чуть менее 4800 записей...
Что я делаю не так?

Почему не работают куки под Pythom/Django?

Почему? Так работает.

Как в Django передать JavaScript-ом токен для метода POST при динамическом обновлении страниц?

У меня с такой конструкцией тоже не получается. Вызывает вместо url: "get_address", корневой скрипт и вместо метода POST переходит на GET....

Как в Django передать JavaScript-ом токен для метода POST при динамическом обновлении страниц?

Самое, блин, странное, что вот так:

data: "address="+$("#address").val()+"&csrfmiddlewaretoken={{ csrf_token }}",

Уже не работает. Вызывает вместо POST, GET и все переменные в нем передает. Почему??

Как в Django передать JavaScript-ом токен для метода POST при динамическом обновлении страниц?

Спасибо. Я уже к этому времени сам нашел. В моем случае вот так сработало:

<script type="text/javascript">
    $(document).ready(function(){
        $('#input_address').submit(function(){
            $.ajax({
                type: "POST",
                url: "get_address",
                data: "csrfmiddlewaretoken={{ csrf_token }}&address="+$("#address").val(),
                success: function(html){
                    $("#box").html(html);
                }
            });
            return false;
        });
    });

    </script>

Почему не работают куки под Pythom/Django?

render_to_response -- обертка HttpResponse. Так что не важно в несколько строк это записать или в одну:

HttpResponse( 'blah' ).set_cookie( 'cookie_name', 'cookie_value' )

Вызов через функцию тоже не должно играть роли.

Почему не работают куки под Pythom/Django?

А попроще никак? :)

Почему не работают куки под Pythom/Django?

И как это поправить?

Куда пойти учеником программиста (Python)?

В моем случае очень потенциально серьезные прибыли. Из-за высокой конкуренции и олигополии на рынке такой сервис лучше сделать как независимое лицо. Иначе не получится после всех игроков накрыть. Те с которыми уже поговорил смотрять одобрительно и ждут работающий

Как организовать в django отношение "родитель -- дочерняя запись" в models красиво?

@sim3x Спасибо. Очень помог. Хочу задать еще один вопрос про авторизацию через django-social-auth ... Похоже вопрос "нубский", но что-то никак не решается... Но из-за своей "нубовости" светить его на ТОСТЕР-е не хочется. Куда тебе постучать, чтобы связаться? URL у тебя в профиле протух.