[Вопрос]

Булка очень хорошо расширяется благодаря систему хуков, одна проблема - они есть не везде. Также одна из типичных проблем при написании хаков - это исправление существующих sql-запросов (не добавление, а именно исправление), которое обычно не сделать без исправления оригинальных файлов. А исправление оригинальных файлов - это совсем не айс при обновлении форума, особенно когда их много этих исправлений.

Поэтому есть задумка сделать вспомогательный продукт расширяющий класс vB_Database (переменные $vbulletin->db / $db и т.п.). Т.е. это позволит исправлять любые sql-запросы в булке на лету, а также использовать систему-хуков до и после любых sql запросах не зависимо от того есть в коде булки рядом хуки или нет.

Поэтому несколько вопросов ко всем кто пишет хаки под булку:

А надо ли это вообще?

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

1. Простая правка добавление хуков в несколько файлов class_core.php class_database_explain.php class_database_slave.php (конечно там не просто добавление, а еще и проверка на наличие класса хуков, но в общем простое добавление кода)

2. Использование полностью своего полноценного класса БД, наследуемого от стандарных классов булки, но тогда придется править init.php на предмет работы с произвольным классом БД, редактировать это:

PHP Code:

    // this is not implemented fully yet
    //    $db = 'vB_Database_' . $vbulletin->config['Database']['dbtype'];
    //    $db =& new $db($vbulletin);
        die('Fatal error: Database class not found'); 


3. Использование полностью своего полноценного класса БД, с подменой переменных $db / $vbulletin->db уже после инициализации стандартного класса булки. Плюс этого метода, что все можно сделать без правки оригинальных файлов, минус - больший расход памяти при работе скрипта (в памяти держится 2 объекта для работы с БД одновременно)

4. Использование полностью своего фейкового (прокси) класса БД, с подменой переменных $db / $vbulletin->db перед запросом и последующим возвратом оригинальных переменных после хука (кстати именно так сделали в последних версиях vboptimize). Плюс метода, аналогичен как у предыдущего метода - не нужны правки оригинальных файлов, но вот минусы - это довольно легкое полное прибитие переменной $db (в 99% случаев для ускорения работы и экономии памяти этот объект передается в булке по ссылке, поэтому для определения того как именно подменить переменную в конкретном месте надо перелопатить довольно много кода, чтобы определить как именно надо подменять эту переменную, хотя для разовых случаев такой способ работает неплохо - vboptimize типичный пример, хотя и там конечно можно было избавится от постоянного пересоздания объектов - ну не сильно быстро это в пхп)

5. Использование переменных функций в стандартном классе БД. ($this->functions). Плюсы - при работе с базой через mysql - не нужна правка оригинальных файлов, минус если используется mysqli, то придется править файл class_core.php. Также плюс этого метода, что не нужны никакие доп.хуки - все можно сделать в стандартных хуках булки - например в init_startup всего лишь надо описать новую функу и подменить ей нужную функу в $db->functions. Пример того что надо исправить в оффтопе:Оффтоп

Хоть у булки в большинстве и красивый код, но вот тут оригинальных разработчиков хочется хорошенько стукнуть, ну почему вместо

PHP Code:

if ($queryresult = mysqli_query($link, $this->sql, ($buffered ? MYSQLI_STORE_RESULT : MYSQLI_USE_RESULT))) 


они не могли написать

PHP Code:

if ($queryresult = $this->functions['query']($link, $this->sql, ($buffered ? MYSQLI_STORE_RESULT : MYSQLI_USE_RESULT))) 


чтобы полностью следовать своей же логики переменных функций???? И самое главное что это идет похоже что с самого начала появления класса mysqli и есть в коде по сей день

Вот кажется все способы как можно подменить работу с базой в булке на свой код.

Интересно услышать мнение разработчиков хаков, какой из методов им будет удобнее использовать при написании хаков и почему (при условии конечно что это кому-то надо).

ммм идея здравая - иногда действительно не хватает хуков в нужных местах и приходится городить костыли
в качестве вариантов.. во-первых смотря под какую ветку.. в 3.8 не так страшно - немного файликов поправить, например как в первом варианте в 4-рке это будет более геморройно.

5. Использование переменных функций в стандартном классе БД. ($this->functions). Плюсы - при работе с базой через mysql - не нужна правка оригинальных файлов, минус если используется mysqli, то придется править файл class_core.php. Также плюс этого метода, что не нужны никакие доп.хуки - все можно сделать в стандартных хуках булки - например в init_startup всего лишь надо описать новую функу и подменить ей нужную функу в $db->functions.

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

бредятина. в булке практически ничего нельзя сделать с запросами - они в массе хорошие, либо написаны так как есть для совместимости с mysql 4.1.
только "обманное кеширование". но это уже не улучшение, а потеря интерактивности.
Кому это нужно, кроме сеонизаторов?

Originally Posted by Cybermama

Не знаю какой процент юзает mysqli

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

Originally Posted by Cybermama

Но ощущается подводный камень... насчёт бесконфликтности с другими хаками.

А какие могут быть конфликты? Если подменять с умом (проверять что именно подменяется), то проблем не должно быть, хотя все конечно от разработчика зависит. С текущими хаками точно проблем не будет, вот если несколько хаков будут одну технологию замены использовать, то есть вероятность что чей-то код не выполнится. Хотя и сейчас много несовместимых между собой хаков.

Originally Posted by netwind

в булке практически ничего нельзя сделать с запросами - они в массе хорошие

я же говорю исправление не для улучшения запросов, а именно для исправления. Бывают хаки где их надо именно исправить для функционала хака. Самый типичный пример вложения в сообщении - чтобы получить доп поля таблицы attachments надо или добавлять допзапрос на каждое вложение или делать один сложный запрос в начале или исправить оригинальный файл.
Кеширование один из вариантов применения, но совсем не основной.

Yoskaldyr добавил 12.07.2010 в 18:21

Originally Posted by Cybermama

в 3.8 не так страшно - немного файликов поправить, например как в первом варианте в 4-рке это будет более геморройно

работа в базой в 4-ке осталась точно такая-же как и в 3-ке, т.е. исправлять все 1 в 1 что в 4-ке что в 3-ке надо будет

Originally Posted by Yoskaldyr

Самый типичный пример вложения в сообщении - чтобы получить доп поля таблицы attachments надо или добавлять допзапрос на каждое вложение или делать один сложный запрос в начале или исправить оригинальный файл.

Самообъединение с этой же таблицей attachments под другим именем напиши.
Поля в $hook_query_fields, join $hook_query_joins .
Проблем выдумал на пустом месте. Или тебя SQL пугает?

Originally Posted by netwind

$hook_query_fields, join $hook_query_joins

а там нет ни хука ни $hook_query_fields, $hook_query_joins, поэтому надо или редактировать код либо делать допзапросы

это в где там ? давай конкретнее
attachment.php :

PHP Code:

($hook = vBulletinHook::fetch_hook('attachment_start')) ? eval($hook) : false;
...
        post.visible AS post_visible, thread.visible AS thread_visible
        $hook_query_fields
..
    LEFT JOIN " . TABLE_PREFIX . "thread AS thread ON (post.threadid = thread.threadid)
    $hook_query_joins 


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

netwind, attachment.php - это для скачивания вложений, а интересует именно отображение ссылок на вложения и дополнительная информация о них в showthread.php где даже намека на хук нет

PHP Code:

        $attachments = $db->query_read("
            SELECT dateline, thumbnail_dateline, filename, filesize, visible, attachmentid, counter,
                postid, IF(thumbnail_filesize > 0, 1, 0) AS hasthumbnail, thumbnail_filesize,
                attachmenttype.thumbnail AS build_thumbnail, attachmenttype.newwindow
            FROM " . TABLE_PREFIX . "attachment
            LEFT JOIN " . TABLE_PREFIX . "attachmenttype AS attachmenttype USING (extension)
            WHERE postid IN (-1" . $ids . ")
            ORDER BY attachmentid
        "); 


Yoskaldyr добавил 12.07.2010 в 18:58

Originally Posted by netwind

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

вообще-то таких мест достаточно много, особенно в админке, а многим хакам ведь нужна интеграция и в админке, чтобы стандартные админ функции не переписывали работу хака.

Yoskaldyr, в целом понятно. Надо было попытаться пропихнуть хуки в hook request thread.
Но раз уж первый запрос достает почти все поля, то второй почти такой же запрос прочитает все те же данные и сильно тормозить не должен.
И вообще, не понимаю стремления к экономии именно ЧИСЛА запросов любой ценой. Многим просто измерять больше нечего, так как остальные показатели производительности скрыты. Но на практике скорее важна ресурсоемкость запросов, а не их число.

Originally Posted by netwind

Но на практике скорее важна ресурсоемкость запросов, а не их число.

полностью согласен, но всетаки в данном случае вопрос стоит не о добавлении/убирании запроса, а в исправлении. Может пример с вложениями не самый удачный, но в админке таких примеров очень много - в некоторых скриптах вообще нет ни одного хука. И вопрос больше не в производительности (хотя и она важна), а в изменении функционала по возможности без исправления или с 1-м исправлением только в одном месте, а не в 20 файлах.

Yoskaldyr добавил 13.07.2010 в 16:55
или все кодеры отдыхают или не кому это не надо :(