shoorick

Функция selectall_arrayref перлового модуля DBI хороша для тех, кому лень писать:

This utility method combines "prepare", "execute" and "fetchall_arrayref" into a single call. It returns a reference to an array containing a reference to an array (or hash, see below) for each row of data fetched.

В большинстве случаев её вполне можно применять, что я и делаю, однако такой подход хорош не всегда: при попытке выполнить такой функцией запрос, возвращающий много данных, потребуется память под все эти данные.

Реальный пример: скрипт, извлекающий тайлы из пакета, созданного Тайлмиллом, пытался читать данные как раз функцией selectall_arrayref. Зная, что применяется запрос

SELECT * FROM tiles

и что представление tiles содержит, помимо прочего, содержимое тайлов, занимающее места больше всего остального, нетрудно догадаться, что попытка выполнения запроса потребует выделения памяти в объёме, сопоставимом с размером файла, в котором сидит база (пакет с тайлами — это база SQLite).

Набор тайлов для территории размером 600×400 км в средних широтах — например, с Челябинском по центру, Ашой на западе, Карталами на юге и Тюменью на северо-востоке — займёт больше гигабайта для набора масштабов не больше шестнадцатого. На практике так и получилось: скрипт отжирал больше гигабайта памяти и всё никак не мог приступить к полезной части, пытаясь отожрать ещё. Если же увеличивать масштаб, затраты вырастут ещё сильнее: добавим семнадцатый зум масштаб — понадобятся ещё три-четыре гигабайта, Добавим восемнадцатый, которого хватит даже для любопытных исследователей карт — ещё на десять-двадцать объём вырастет. Если будем сохранять тайлы с глубиной цвета 24 бита, а не восемь — ещё больше места израсходуем. Получается, что средних размеров российская область может занять своими тайлами десятки гигабайт. И скрипт бы безуспешно пытался эти десятки получить.

Переписал:

-my $tiles = $dbh->selectall_arrayref(
-    'SELECT * FROM tiles',
-    { Slice => {} },
-);
-
-foreach my $tile ( @$tiles ) {

+my $sth = $dbh->prepare('SELECT * FROM tiles');
+   $sth->execute;
+
+while ( my $tile = $sth->fetchrow_hashref ) {

и всё наладилось: скрипт перестал жрать память (ему хватило десяти мегабайт) и ждать её выделения — сразу работает.

Вывод: не всегда надо экономить рабочее время программиста — иногда надо и о машинном времени задумываться.

http://shoorick.ru/2015/08/26/more-code/

Похоже, в друпале придётся применять тот же способ, как и в одном из предшествующих сайтов — отказаться от всяческих абстракций в пользу чистого SQL. Если, конечно, он предусмотрен.

Поглядев статистику потраченного друпалом времени и количества запросов к СУБД, офигел весь был неприятно удивлён: на формирование страницы со списком подмножества опубликованных статей друпал потратил от 100 до 11 тысяч запросов, что заняло от 2 секунд до более чем полутора минут. Это как так?

Я, конечно, понимаю, что время программиста сейчас ценится выше машинного времени плюс друпалу на отрисовку страницы ещё нужны кое-какие ресурсы, но это не может служить оправданием того безобразия, что я наблюдаю: сидя дома, не имея под рукой эпического полотна со структурой хотя бы части БД, я минут за 10 написал и отладил SQL-запрос, который формирует тот же самый список статей и при этом выполнение запроса укладывается в десятки миллисекунд. На то, чтобы понять, как работают Views, и поэкспериментировать с ними, я потратил часы и дни. И всё равно толком не понял.

Это я такое написал? Проще уж на обычном SQL писать...

$c->stash->{'checkpoints'} = [
    $c->model($MODEL)->search(
        {
            'stgroup_id.id'           => $student->stgroup_id->id,
            'checkresults.student_id' => [ $student->id, undef ],
        },
        {
            'select'   => [ \'me.name cpname', qw/me.id me.date max_ball/ ],
            'join'      => [
                'checkresults', {
                    'tss_id' => [
                        qw/stgroup_id subject_id/,
                        { 'teacher_id' => 'user_id' }
                    ],
                }
            ],
            '+columns'  => [
                qw/subject_id.name checkresults.ball/,
                qw/user_id.fname user_id.sname user_id.lname/,
            ],
#             '+as'       => [ qw/subject_name ball/ ],
            'order_by'  => [ qw/date/ ],
        },
    )
];

Поглядев на терзание сервера баз данных нашей поделкой, решил попробовать другой метод: DBIx::Class, вроде бы, позволяет выполнять произвольный SQL-запрос. Запрос-то я написал и протестировал, да вот подсунуть его каталисту пока не получается...

Пойду-ка домой, ужинать и читать мануалы.

Задавшись целью отслеживать в траке (trac) свежие тикеты (таймлайн для этого не совсем удобен, ибо содержит массу других событий и фиксирует только появление/закрытие/повторное открытие) и комментарии к ним, нашёл механизм: через отчёты.

Сделал ( три отчёта )

Получил искомое. Доволен.

Вместо ковыряния в отсутствующей доке найдён более весёлый путь: трафик меж клиентом (готовой гуёвой софтиной) и сервером снюхивается. Например, ызырилом. После чего выясняется, что и запросы и ответы ходят в открытом виде (правда, в разных кодировках, но это уже не важно), после чего наступает Щастье™.

upd: Чтоб не забыть, фильтр:
tds.type == 0x1
оставляет только запросы.

Оказывается, в MySQL временные таблицы не могут использоваться в одном запросе более одного раза.
А у меня она используется семь раз.
В результате чего мне прилетает Error 1137: Can't reopen table.
Абыдна!

upd: Пришлось создавать семь временных таблиц...

Новый МыМанагер рулит.
Осталось ещё mysql на сервере заапгрейдить.
Ибо 3.23 устарел нафиг. Народ-то уже пятым пользуется...

Два рабочих дня усиленного ковыряния в MSSQL и перле, сопровождающегося напряжением мозгов, подошли к концу.

Краткие выводы:

0. SQL надо было всё-таки на 4-5 курсе учить, а не сейчас;
1. SELECT — он и в Африке SELECT
2. IPSoft (у них даже сайт не работает!) хелп к собственному продукту пишут через... Ну все поняли.


3. скрипт работает!

P. S. Можно идти отмечать День всемирной солидарности трудящихся.
Ура, товарищи!

Чтоб самому потом не забыть:

SELECT *,(d2>=d3 AND d1<=d4) AS cmp FROM `test_ival`

Возвращает 1 в случае пересечения диапазонов [d1; d2] c [d3; d4] и 0 в противном случае.
Если вместо >= и <= использовать соответственно > и <, получится проверка пересечения (d1; d2) c (d3; d4).