Булка очень хорошо расширяется благодаря систему хуков, одна проблема - они есть не везде. Также одна из типичных проблем при написании хаков - это исправление существующих 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 код:
// 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 код:
if ($queryresult = mysqli_query($link, $this->sql, ($buffered ? MYSQLI_STORE_RESULT : MYSQLI_USE_RESULT)))
они не могли написать
PHP код:
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.
только "обманное кеширование". но это уже не улучшение, а потеря интерактивности.
Кому это нужно, кроме сеонизаторов?
довольно большой, и используют хотя бы из-за того, что mysqli быстрее mysql.
Цитата:
Сообщение от Cybermama
Но ощущается подводный камень... насчёт бесконфликтности с другими хаками.
А какие могут быть конфликты? Если подменять с умом (проверять что именно подменяется), то проблем не должно быть, хотя все конечно от разработчика зависит. С текущими хаками точно проблем не будет, вот если несколько хаков будут одну технологию замены использовать, то есть вероятность что чей-то код не выполнится. Хотя и сейчас много несовместимых между собой хаков.
Цитата:
Сообщение от netwind
в булке практически ничего нельзя сделать с запросами - они в массе хорошие
я же говорю исправление не для улучшения запросов, а именно для исправления. Бывают хаки где их надо именно исправить для функционала хака. Самый типичный пример вложения в сообщении - чтобы получить доп поля таблицы attachments надо или добавлять допзапрос на каждое вложение или делать один сложный запрос в начале или исправить оригинальный файл.
Кеширование один из вариантов применения, но совсем не основной.
Yoskaldyr добавил 12.07.2010 в 18:21
Цитата:
Сообщение от Cybermama
в 3.8 не так страшно - немного файликов поправить, например как в первом варианте в 4-рке это будет более геморройно
работа в базой в 4-ке осталась точно такая-же как и в 3-ке, т.е. исправлять все 1 в 1 что в 4-ке что в 3-ке надо будет
Последний раз редактировалось Yoskaldyr; 12.07.2010 в 18:21..
Причина: Добавлено сообщение
Самый типичный пример вложения в сообщении - чтобы получить доп поля таблицы attachments надо или добавлять допзапрос на каждое вложение или делать один сложный запрос в начале или исправить оригинальный файл.
Самообъединение с этой же таблицей attachments под другим именем напиши.
Поля в $hook_query_fields, join $hook_query_joins .
Проблем выдумал на пустом месте. Или тебя SQL пугает?
netwind, attachment.php - это для скачивания вложений, а интересует именно отображение ссылок на вложения и дополнительная информация о них в showthread.php где даже намека на хук нет
PHP код:
$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
Цитата:
Сообщение от netwind
я допускаю, что где-то их нет, но это лишь значит, что ты избрал совсем редкий никому не нужный запрос. обычно все есть.
вообще-то таких мест достаточно много, особенно в админке, а многим хакам ведь нужна интеграция и в админке, чтобы стандартные админ функции не переписывали работу хака.
Последний раз редактировалось Yoskaldyr; 12.07.2010 в 18:58..
Причина: Добавлено сообщение
Yoskaldyr, в целом понятно. Надо было попытаться пропихнуть хуки в hook request thread.
Но раз уж первый запрос достает почти все поля, то второй почти такой же запрос прочитает все те же данные и сильно тормозить не должен.
И вообще, не понимаю стремления к экономии именно ЧИСЛА запросов любой ценой. Многим просто измерять больше нечего, так как остальные показатели производительности скрыты. Но на практике скорее важна ресурсоемкость запросов, а не их число.
Но на практике скорее важна ресурсоемкость запросов, а не их число.
полностью согласен, но всетаки в данном случае вопрос стоит не о добавлении/убирании запроса, а в исправлении. Может пример с вложениями не самый удачный, но в админке таких примеров очень много - в некоторых скриптах вообще нет ни одного хука. И вопрос больше не в производительности (хотя и она важна), а в изменении функционала по возможности без исправления или с 1-м исправлением только в одном месте, а не в 20 файлах.
Yoskaldyr добавил 13.07.2010 в 16:55
или все кодеры отдыхают или не кому это не надо :(
Последний раз редактировалось Yoskaldyr; 13.07.2010 в 16:55..
Причина: Добавлено сообщение
Перехват класса vB_Database
или не кому это не надо :(
Линейный вид
