Сортировка. Чисто технический вопрос.

[wwwserfer]

Приветствую!

Перед объединением 2-х SMF форумов и работой с БД я с удивлением обнаружил такую весчь (на примере личных сообщений юзеров): оказывается сортировка личных сообщений пользователя происходит по ID_PM почему то, а не по msgtime (микротайм, как я понял) - это с чем то связано? Отразится ли как то на форуме (станет тормозить, будут сбои или проч.), если я изменю данный порядок сортировки с ID_PM на msgtime при выдаче результатов?

Кстати, как я уже выше заметил, данный порядок сортировки установлен не только к личным сообщениям, но и к сообщениям пользователей на форуме, к примеру, при просмотре оставленных сообщений на форуме в профиле пользователей (сортировка по ID_MSG, но никак не по posterTime) и еще к некоторым вещам. Почему так?

Спасибо за внимание!

P.S. SMF 1.1.16

[chilly86]

это Вы в phpmyadmin смотрите?
так там по умолчанию сортировка идет по первому столбцу...

[maestrosite.ru]

ID_* - это _уникальные_ идентификаторы сообщений, тем, и тд. Присваиваются они автоматически по возрастающей, то есть очередь по идентификаторам соответствует очереди по времени создания. Кроме этого, идентификаторы уже находятся в индексе базы. То есть для выборки объектов по времени создания нет необходимости плодить лишнюю сущность.

[wwwserfer]

это Вы в phpmyadmin смотрите?
так там по умолчанию сортировка идет по первому столбцу...

Да нет же... при чем тут phpmyadmin.........?
Я смотрю сортировку в файлах скрипта.

ID_* - это _уникальные_ идентификаторы сообщений, тем, и тд. Присваиваются они автоматически по возрастающей, то есть очередь по идентификаторам соответствует очереди по времени создания. Кроме этого, идентификаторы уже находятся в индексе базы.

Да, это все понятно, но.... как я уже сказал - объединяются 2 форума, соответственно СТАРЫЙ объединяемый ФОРУМ последнее ID (любое, будь то personal_messages, messages, topics и пр. ) будет переписано, последним ID с НОВОГО ФОРУМА + i. Правильно что-ли объяснил? =))

Так вот поэтому я и задал такой вопрос -  можно ли изменить сортировку "без последствий"? Чтобы после объединения форумов не было путаницы, связанной с сортировкой по ID, по умолчанию...

[maestrosite.ru]

Да, это все понятно, но.... как я уже сказал - объединяются 2 форума, соответственно СТАРЫЙ объединяемый ФОРУМ последнее ID (любое, будь то personal_messages, messages, topics и пр. ) будет переписано, последним ID с НОВОГО ФОРУМА + i. Правильно что-ли объяснил? =))

Так вот поэтому я и задал такой вопрос -  можно ли изменить сортировку "без последствий"? Чтобы после объединения форумов не было путаницы, связанной с сортировкой по ID, по умолчанию...

Если я правильно понял вашу задумку, то это выглядит примерно так. Делаете "потабличную" выборку из обеих баз с сортировкой по дате(!) и вставляете в итоговую базу без идентификаторов. Далее придётся восстановить соответствие тема-сообщение, сообщение-автор и тд. Если вам действительно нужна такая махинация, то рекомендую в исходных таблицах создать уникальные ключи. Уникальные для обеих баз, например во второй базе стартовые ид = 1000000. Тогда соответствие установить будет делом техники.

[wwwserfer]

Спасибо всем за ответы!

Вообщем, оставим в покое базу. И займемся сортировкой тем по posterTime взамен сортировки по ID_MSG, путем редактирования файлов скрипта. (Да, я знаю, что данная сортировка несколько замедлит работу движка). Ситуация такая: я внес некоторые изменения в скрипт, но не все верно работает... Подскажите пожалуйста, где я ошибся и что пропустил..

Требуется сортировка по posterTime тем на главной форума, а также в разделах (список тем).
Что я поменял: файл Sources/MessageIndex.php

поменял

Код Выделить Развернуть

'last_post' => 't.ID_LAST_MSG'

на:

Код Выделить Развернуть

'last_post' => 'ml.posterTime'

поменял

Код Выделить Развернуть

$_REQUEST['sort'] = 't.ID_LAST_MSG';

на:

Код Выделить Развернуть

$_REQUEST['sort'] = 'ml.posterTime';

поменял:

Код Выделить Развернуть

'first_post' => 't.ID_TOPIC',

на:

Код Выделить Развернуть

'first_post' => 'mf.posterTime',

В файле Sources/Display.php:

поменял дважды:

Код Выделить Развернуть

ORDER BY ID_MSG

на:

Код Выделить Развернуть

ORDER BY posterTime

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

Ошибка базы данных

Unknown column 'ml.posterTime' in 'order clause'
Файл: D:\htdocs\test.lan\Sources\MessageIndex.php
Строка: 438

[maestrosite.ru]

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

1. Главная страница - /Sources/BoardIndex.php
2.

Код Выделить Развернуть

443: t.ID_LAST_MSG, ml.posterTime AS lastPosterTime, ml.ID_MSG_MODIFIED,
то есть в сортировке указывайте lastPosterTime

[wwwserfer]

Unknown column 'lastPosterTime' in 'order clause'
Файл: D:\htdocs\test.lan\Sources\MessageIndex.php
Строка: 438

Или я чо туплю?

[maestrosite.ru]

Или я чо туплю?

Покажите весь запрос, как он у вас сейчас выглядит

[wwwserfer]

Судя по всему, ошибку постраничного просмотра тем вызывает этот запрос в MessageIndex.php:

Код Выделить Развернуть

$request = db_query("
SELECT t.ID_TOPIC
FROM ({$db_prefix}topics AS t" . ($context['sort_by'] === 'last_poster' ? ", {$db_prefix}messages AS ml" : (in_array($context['sort_by'], array('starter', 'subject')) ? ", {$db_prefix}messages AS mf" : '')) . ')' . ($context['sort_by'] === 'starter' ? "
LEFT JOIN {$db_prefix}members AS memf ON (memf.ID_MEMBER = mf.ID_MEMBER)" : '') . ($context['sort_by'] === 'last_poster' ? "
LEFT JOIN {$db_prefix}members AS meml ON (meml.ID_MEMBER = ml.ID_MEMBER)" : '') . "
WHERE t.ID_BOARD = $board" . ($context['sort_by'] === 'last_poster' ? "
AND ml.ID_MSG = t.ID_LAST_MSG" : (in_array($context['sort_by'], array('starter', 'subject')) ? "
AND mf.ID_MSG = t.ID_FIRST_MSG" : '')) . "
ORDER BY " . (!empty($modSettings['enableStickyTopics']) ? 'isSticky' . ($fake_ascending ? '' : ' DESC') . ', ' : '') . $_REQUEST['sort'] . ($ascending ? '' : ' DESC') . "
LIMIT $start, $maxindex", __FILE__, __LINE__);
$topic_ids = array();
while ($row = mysql_fetch_assoc($request))
$topic_ids[] = $row['ID_TOPIC'];

[maestrosite.ru]

да, в этом запросе таблица ml подключается только если задана сортировка по крайнему постеру:

Код Выделить Развернуть

($context['sort_by'] === 'last_poster' ? ", {$db_prefix}messages AS ml" :

[wwwserfer]

неужели никто не задавался данным вопросом в русском сообществе SMF?
на simplemachines.org есть такие темы, но тупиковые.. да и решения, опубликованные там - не работают.

Готов заплатить за рабочую подсказку по теме.

P.S. Модераторы, если требуется перемещение темы в "Предложения по работе", переместите пожалуйста...

[maestrosite.ru]

неужели никто не задавался данным вопросом в русском сообществе SMF?
на simplemachines.org есть такие темы, но тупиковые.. да и решения, опубликованные там - не работают.

Готов заплатить за рабочую подсказку по теме.

P.S. Модераторы, если требуется перемещение темы в "Предложения по работе", переместите пожалуйста...

Так добавьте подключение таблицы. Вместо

Код Выделить Развернуть

($context['sort_by'] === 'last_poster' ?
в двух местах запроса поставьте

Код Выделить Развернуть

( ($context['sort_by'] === 'last_poster'  || $context['sort_by'] === 'last_post') ?


upd
Ну и маленькая ремарка. Посмотрите  в сторону переписывать значения id_last_msg в таблице тем. Если есть возможность навесить триггеры на таблицы, то править код вообще не придётся. Думаю это будет лучший вариант.

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

[wwwserfer]

Прежде всего СПАСИБО!

Вот это действительно помогло:

Так добавьте подключение таблицы. Вместо

Код Выделить Развернуть

($context['sort_by'] === 'last_poster' ?

в двух местах запроса поставьте

Код Выделить Развернуть

( ($context['sort_by'] === 'last_poster'  || $context['sort_by'] === 'last_post') ?

Осталось теперь как-то избавится от постоянной ошибки в логах форума:

Код Выделить Развернуть

Undefined index: sort_direction
Файл: D:\test.lan\Themes\default\MessageIndex.template.php (main sub template - eval?)
Строка: 163

Ошибка возникает при постраничном просмотре списка топиков (как мне кажется...)

Сама 163 из MessageIndex.template.php:

Код Выделить Развернуть


<td class="catbg3" width="22%">
<a href="', $scripturl, '?board=', $context['current_board'], '.', $context['start'], ';sort=last_post', $context['sort_by'] == 'last_post' && $context['sort_direction'] == 'up' ? ';desc' : '', '">', $txt[111], $context['sort_by'] == 'last_post' ? ' <img src="' . $settings['images_url'] . '/sort_' . $context['sort_direction'] . '.gif" alt="" />' : '', '</a></td>';

Подскажете?

upd
Ну и маленькая ремарка. Посмотрите  в сторону переписывать значения id_last_msg в таблице тем. Если есть возможность навесить триггеры на таблицы, то править код вообще не придётся. Думаю это будет лучший вариант.

Тут, не лукавя скажу - не имею понятия как это делается...

upd2 даже ещё проще
Так как базы вы уже объединили, то новые сообщения будут сами по себе обновлять ид крайнего сообщения, и со временем само собой должно устаканиться.

Конечно, если сейчас значение автоинкремента больше максимального имеющихся в записях.

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

Это да, но слишком много "старых" тем повиснут над новыми во многих разделах форума. Ждать придется от полугода до года, прежде чем рассовывать темы по разделам.

Значение автоинкремента больше на 1 максимального имеющихся в записях.

Так а при этом разьве не поменяются ID. ... что приведет к битым внутренним ссылкам, не говоря уже про поисковики. Я не прав?

[maestrosite.ru]

Осталось теперь как-то избавится от постоянной ошибки в логах форума:

Код Выделить Развернуть

Undefined index: sort_direction
Файл: D:\test.lan\Themes\default\MessageIndex.template.php (main sub template - eval?)
Строка: 163

Ошибка возникает при постраничном просмотре списка топиков (как мне кажется...)

стало быть вы слегка удалили строку в том же самом MessageIndex.php:

Код Выделить Развернуть


395: $context['sort_direction'] = $ascending ? 'up' : 'down';


Тут, не лукавя скажу - не имею понятия как это делается...

Это да, но слишком много "старых" тем повиснут над новыми во многих разделах форума. Ждать придется от полугода до года, прежде чем рассовывать темы по разделам.

Значение автоинкремента больше на 1 максимального имеющихся в записях.

Так а при этом разьве не поменяются ID. ... что приведет к битым внутренним ссылкам, не говоря уже про поисковики. Я не прав?

Нет, внешне ничего не изменится, ссылки будут целыми.

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

[wwwserfer]

Спасибо еще раз!

И не подскажите, как подправить, чтобы в + ко всему сортировка последних сообщений при просмотре главной страницы форума была также по posterTime. Я так понимаю что это в BoardIndex.php где-то?

Я про это:

[maestrosite.ru]

Спасибо еще раз!

И не подскажите, как подправить, чтобы в + ко всему сортировка последних сообщений при просмотре главной страницы форума была также по posterTime. Я так понимаю что это в BoardIndex.php где-то?

Я про это:

Я бы просто в базе исправил значение ID_LAST_MSG, в таблице {db_prefix}boards. Это флаг, и значение будет обновляться ещё быстрее, чем в разделе (в списке тем). И вряд ли это большой список не правильных сообщений.

Насколько я вижу, вам актуальнее даже не на главной, а в подразделах. Если же обновить всё, то и это не проблема - несколько запросов в базу.