anonymous@RULINUX.NET~# | Last login: 2024-11-23 04:01:20 |
Регистрация Вход | Новости | Разметка | Пользователи | Галерея | Форум | Статьи | Неподтвержденное | Трекер | Правила форума | F.A.Q. | Ссылки | Поиск |
Форум - Rulinux.net | [RSS] |
Раз уж исходники стали более-менее доступны, предлагаю прикрепить в этом разделе тему с предложениями по их улучшению. Для затравки два предложения:
1. Повыбрасывать из кода в classes/*.class.php вызовы "mysql_close();" - насколько я понимаю, из-за этих вызовов каждый вызов метода класса будет переустанавливать соединение к БД.
Да и пролог, устанавливающий соединение к БД, выбирающий зачем-то базу и устанавливающий кодировку для сессии - лучше куда-нить в глобальный инклюд вытащить и делать это всё однократно при инициализации обработки запроса, чем на каждый вызов метода.
2. Из метода pages::get_meta_data (classes/pages.class.php) следующие строки:
ибо возвращённое значение нигде не проверяется (и при пустом наборе данных даёт ошибки при использовании в foreach, например в incs/header.inc.php), а пустой массив - вполне адкватная репрезентация пустого набора данных
anonymous(*) (2009-05-11 18:03:12)
|
|
|
Скрыть
Re:Прием патчей к исходникам LOR-NG> мало ли где понадобится его проверка -1 там говорит, что не нашлось строк в наборе данных. То же самое скажет и пустой массив. Если понадобится проверка - можно просто будет проверить длину массива. |
Скрыть
Re:Прием патчей к исходникам LOR-NG> Нечего оправдываться и переводить стрелки на туксойда - никто же не говорю, что разработчиков надо убить прямо сейчас :) Я говорю про то что времени не было их досканально просмотреть :-) > это не оптимизация а то, что хотелось бы поиметь пд оптимизацией я имел в виду минимизацию вызовов к СУБД > Вообще, было бы неплохо если бы разрабы взяли бы за правило складывать сорцы в конце дня куда-нить в ФС сервера, раз уж cvs пока нет. Да погоди, свн скоро будет уже |
Скрыть
Re:Прием патчей к исходникам LOR-NG> Да погоди, свн скоро будет уже Через неделю я уеду в отпуск, а за это время мог бы попробовать наваять трекер.пхп (в принципе я тоже на пыхе не писец). |
Скрыть
Re:Прием патчей к исходникам LOR-NGА можешь в forum.php заменить последовательность действий: $ath = mysql_query("INSERT INTO forum_threads(name, user_name, posting_date, forum_id) VALUES('$title', '$username', '$posting_date', '$forumid')"); ... $tbl = mysql_query("SELECT thread_id FROM forum_threads WHERE name = '$title' AND posting_date = '$posting_date' AND forum_id = '$forumid'"); ... $thr = mysql_fetch_array($tbl); $thread_id = $thr['thread_id']; на: $ath = mysql_query("INSERT INTO forum_.... $thread_id = mysql_insert_id($ath); И не понял для чего после создания треда повторно брать дату для сообщения, а потом апдейтить тред новой датой. Наверное это можно закоментить нафиг. Вообще, хотелось бы в базе иметь timestamp'ы и даты в полях типа timestamp а не в виде строки или целого. Можешь добавить колонку created_at типа timestamp в таблицы news, comments, forum_messages, forum_threads etc? Они будут автоматически инициализироваться текущим временем при создании записи. И ещё хотелось бы поиметь полный набор сорцов, включая файлик view-message.php и х/з что там ещё было пропущено. Тестовый набор данных был бы тоже не вреден. |
Скрыть
Re:Прием патчей к исходникам LOR-NGфорум Туксойд писал, я его исходники хоть и правил, но не оптимизировал |
Скрыть
Re:Прием патчей к исходникам LOR-NGНечего оправдываться и переводить стрелки на туксойда - никто же не говорю, что разработчиков надо убить прямо сейчас :) К тому же таймстампы, актуальные сорцы и тестовые данные - это не оптимизация а то, что хотелось бы поиметь, что бы тракер.пхп пририсовать. Вообще, было бы неплохо если бы разрабы взяли бы за правило складывать сорцы в конце дня куда-нить в ФС сервера, раз уж cvs пока нет. |
Скрыть
Re:Прием патчей к исходникам LOR-NG |
Скрыть
Re:Прием патчей к исходникам LOR-NG |
Скрыть
Re:Прием патчей к исходникам LOR-NG |
Скрыть
Re:Прием патчей к исходникам LOR-NG> Повыбрасывать из кода в classes/*.class.php вызовы "mysql_close();" - насколько я понимаю, из-за этих вызовов каждый вызов метода класса будет переустанавливать соединение к БД. не, так было давно. Сейчас в действительности имеется пул соединений, и при запросе соединения с бд новое обычно не создаётся, а используется из пула. При mysql_close() соединение не закрывается, а возвращается в пул и может быть повторно использовано при новом запросе. Убирание вызовов mysql_close() в действительности мало на что повлияет, так как по завершении скрипта все его открытытые дескрипторы всё равно закрываются. bugmaker(*)(2009-05-22 07:14:46)
Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4 |
|
|
|
Этот тред читают 2 пользователя: |
Анонимных: 2 Зарегистрированных: 0 |
Re:Прием патчей к исходникам LOR-NG
> 1. Повыбрасывать из кода в classes/*.class.php вызовы "mysql_close();"
Принято. Начинал писать достаточно сумбурно, а сейчас все руки не доходят подобный мусор выкинуть
> 2. Из метода pages::get_meta_data (classes/pages.class.php) следующие строки:
ИМХО, лучше оставить return, mysql_close естественно выбросить. А тут - мало ли где понадобится его проверка
Opera/9.64 (X11; Linux i686; U; en) Presto/2.1.1