Текст первого сообщения темы на странице форума?

[helpix]

Есть желание на страницу форума (т.е. на ту страницу, где присутствует список заголовков тем для данного форума) вывести для каждой темы не только ее заголовок/описание и т.д., но и целиком первое сообщение данной темы (то, которое создается при создании темы).

 

Насколько я понял, за вывод строки по теме отвечает шаблон

+-- Normal Topic Entry

из Forum Index Sections

 

Но сильно подозреваю, что среди данных, которые имеются в момент отрисовки данных строк, ничего похожего на первое сообщение нет.

 

Никто, случайно, не знает, что тут можно сделать?

 

Форум у меня - 1.3.1

[Song]

helpix

там нужно запросик менять.

Такой запросик есть в моде Topic Hints.

Только тебе весь мод не нужен, а только лишь его часть, связанная с измением запроса в Forums.php

После этого в скиновом файле просто включишь его в таблицу через $data['post']

 

P.S. В большом форуме замедление будет заметно.

[helpix]

Song, спасибо.

 

Примерно то, что нужно. Но вот замедление... Это плохо. Скажи, а в forums.php в момент выполнения указанных запросов известнен ли уже скин? Т.е. мне это нужно не всегда, а только если для форума указан один единственный конкретный скин. Я бы тогда просто сделал там ветвление. Если скин такой - делать "медленный" запрос. Если любой другой - пусть все будет как обычно быстро.

[Song]

helpix

Скажи, а в forums.php в момент выполнения указанных запросов известнен ли уже скин?

Конечно.

$ibforums->skin_rid

[helpix]

Вах, работает. А название скина, случайно, там же не доступно? Наверное, было бы корректнее засовывать в код его, а не идентификатор.

[urisoft]

helpix

Но вот замедление... Это плохо.

По поводу "медленного" запроса...

Сделай так:

Найди в forums.php строки:

while ( $topic = $DB->fetch_row() )
{
$this->output .= $this->render_entry( $topic );
$total_topics_printed++;
}

Замени на:

$topic_list = array();
while ( $topic = $DB->fetch_row() )
{
if ($topic['state'] == 'link')
{
 $t_array = explode("&", $topic['moved_to']);
 $topic_list[] = $t_array[0];
}
else
{
 $topic_list[] = $topic['tid'];
}
$this->output .= $this->render_entry( $topic );
$total_topics_printed++;
}
$post_list = array();
if (count($topic_list))
{
$DB->query("SELECT topic_id, post FROM ibf_posts WHERE topic_id IN (".implode(", ",$topic_list).") AND new_topic=1");
while ($row = $DB->fetch_row())
{
 $post_list[$row['topic_id']]['post'] = $row['post'];
}
}

foreach ($topic_list as $tid)
{
$this->output = str_replace("<!--myID_".$tid."-->",$post_list[$tid]['post'],$this->output);
}

Добавь новый индекс:

ALTER TABLE ibf_posts ADD INDEX new_topic (topic_id, new_topic);

 

И в шаблон вставляй код:

<!--myID_{$data['tid']}-->

 

IMHO это самый быстрый вариант. При 500 тыс. постах дает максимальную скорость из вариантов мной проверенных.

Тот запрос, что в TopicHints действительно на большом кол-ве постов жутко тормозит.

[Song]

urisoft

а зачем индекс на topic_id если он уже есть в таблице?

Добавлено в [mergetime]1104952398[/mergetime]

IMHO это самый быстрый вариант.

 

Я давно уже так сделал.

Причём я пошёл ещё дальше. Я убрал JOIN в стандартном запросе (тот, который даёт DISTINCT(author_id)) и сделал его в том же самом цикле. Чего разгрузило запрос ещё больше.

[urisoft]

Song

а зачем индекс на topic_id если он уже есть в таблице?

Индекс не на topic_id, а на группу (topic_id, new_topic).

Просто по topic_id просматриваются все посты содержащие данный topic_id, а по добавленному выше индексу только посты с указанным topic_id и new_topic.

По эксплайну так намного эффективнее... Просмотр 15 (отображаемые темы на странице) записей против 15-1000 (зависит от кол-ва ответов в теме).

Сам проверь.

 

Добавлено в [mergetime]1104952811[/mergetime]

Song

Я давно уже так сделал.

Как обычно... Сделал и молчит.

Только критикует по маленькому...

Нет что бы заблудившихся на путь истинный вернуть

[Song]

Индекс не на topic_id, а на группу (topic_id, new_topic).

А без разницы.

Составной индекс делается для увеличения эффектиновсти индекса только в том случае, если запрос по обоим полям идёт всегда группой. А у тебя topic_id ещё много где используется.

А если ты делаешь составной ещё поверх основного это приведёт только к не обоснованному росту индекса. Особенно для такой большой таблицы. При обновлении (INSERT, UPDATE) он будет долго перестраиваться - это ведь бинарные деревья, и в случае когда один индекс зависит от другого они ещё и тормозить будут. А самое главное что ничего не даст.

Поэтому моё ИМХО - если нужно делаешь индекс на new_topic и всё.

Добавлено в [mergetime]1104954114[/mergetime]

Просто по topic_id просматриваются все посты содержащие данный topic_id, а по добавленному выше индексу только посты с указанным topic_id и new_topic.

Ну и что. Но ты же добавь ещё отдельный new_topic. И он будет при пересмотре смотреть по 2-м индексам.

Добавлено в [mergetime]1104954208[/mergetime]

Как обычно... Сделал и молчит.

эээ.. так у меня 50%-то форума переписано точно

это мне говорить и говорить и говорить

за флуд выгонят )

[urisoft]

Song

А самое главное что ничего не даст.

Поэтому моё ИМХО - если нужно делаешь индекс на new_topic и всё.

А ведь даёт...

Убил я свой индекс, добавил просто new_topic и получил тоже, что и без него. Используется только topic_id и просмотр всех записей темы.

Если обычно на форуме мало ответов, то и без добавления индексов сойдет. А вот если много.......

Для примера: (все запросы не кэшированные, в том числе и индекс. Для наглядности).

В базе:

100000 тем.

400640 ответов.

(500640 постов всего).

20 форумов.

Выполнялся запрос:

SELECT topic_id, post FROM ibf_posts WHERE topic_id IN (".implode(", ",$topic_list).") AND new_topic=1

В topic_list 15 тем. В выбранных темах 500 ответов.

 

Без добавления индекса:

- время выполнения 0.86951,

- доступные индексы topic_id

- использованный индекс topic_id

- просмотрено строк 515.

При добавлении индекса new_topic:

- время выполнения 0.87328,

- доступные индексы topic_id, new_topic

- использованный индекс topic_id

- просмотрено строк 515.

При добавлении группового индекса:

- время выполнения 0.13859,

- доступные индексы topic_id, new_topic

- использованный индекс new_topic

- просмотрено строк 15.

 

Так что я бы не сказал, что это бесполезно. Тем более что просмотр списка тем практически самое часто используемое место на форуме (IMHO).

Я опять ошибаюсь ?

Добавлено в [mergetime]1104962701[/mergetime]

Хм... может я тебя не так понял ?

Может ты имел ввиду добавить new_topic в существующую группу topic_id ?

так наверное было бы эффективнее...

[Song]

Какая версия мускула?

На 3-ем такая феня ничего не даёт.

 

Если в 4-ом рулит, то очень хорошо, но индекс сильно увеличивается.

[urisoft]

Song

Какая версия мускула?

3.23.56-nt на WinXP все стоит.

 

На 3-ем такая феня ничего не даёт.

Незнаю... Я выше привел пример со своей локалки. Еслиб сам не увидел, не писал бы.

Добавление написанного мной выше индекса реально уменьшает время выполнения этого конкретного запроса.

 

Надо будет протестить вариант с добавлением new_topic в существующую группу topic_id.

[Song]

Надо будет протестить вариант с добавлением new_topic в существующую группу topic_id.

бессмысленно, потому как он будет правым индексом в группе многосоставного.

 

urisoft может быть. И хорошо бы так. Но у меня никого performance я не заметил, поэтому подтвердить не могу, ну и как оказалось теперь и опровергнуть не могу

Будем считать что ты прав.