Разделение ПОСТА

[Dr.Freddy]

Song, идея понятна — получим выигрыш во времени по сравнению с простой сортировкой по post_date. Думаю, вечером напишу.

 

Кстати, сразу хочу уточнить. Насколько большим будет этот выигрыш, если в силу ситуации на определённом форуме переключать сортировку с Post Date на Post ID нельзя и ограничиться можно только перепрошивкой mod_func_get_last_post по твоей схеме?

[Anna]

Т.е. логика «пост не скрыт» по-другому записана.

 

поправила - посмотри.

 

Чего-то вы такое интересное придумали - мне не объясните

[DJ_KISSLOTNIY]

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

Может не стоит велосипед выдумывать и все усложнять, будет ли эта гибкость к которой вы хотите довести мод, востребованной или же людям действительно хватит и того о чем я только что написал? [1124091893:1124092341]Не подумайте, что я вмешиваюсь, не те у меня знания чтоб давать советы по таким вещам, но не могу чисто от себя не сказать вот что. Я в модах ценю в первую очередь как можно меньшее вмешательство и изменение в базе форума, особенно в таких важных вещах которые касаются таблиц, которые желательно не изменять, чтоб не возникало проблем при апгрейде базы до новой версии движка. А табличы posts, topics и т.д. как раз являются важными и их вообще не желательно трогать

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

[Dr.Freddy]

Anna, всё правильно.

 

DJ_KISSLOTNIY, из спортивного интереса! А если серьёзно, ты тогда нужно писать модераторам очень-очень серьёзную инструкцию — чтобы разделяли посты исключительно в порядке их появления в топике. Иначе при после перемещения (хотя нет, даже сразу, после «разделения») они перепутаются чёрти-как.

 

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

 

В общем несистемный это подход...

 

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

Донт ворри, би хэппи! Не повлияет.

[Song]

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

 

вот у таких админов доски и тормозят

Не знаю как в двойке, но в структуре базы 1.2 стоооолько ###вна, что пришлось половину типов полей менять и половину индексов перестраивать.

 

>> и то что вы хотите добавить еще одно поле в таблицу никак не полияет на конвертирования

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

 

К сожалению я не знаю как оценить выйгрыш.

Одно могу сказать, что и

 

order by post_date

 

и

 

order by pid,sort

 

и

 

order by new_topic desc, post_date

 

всё плохо.

 

Но, если сортировка по post_date больше нигде глюков не даст (например в модераторских функциях), то лучше оставить её.

К тому же не забудьте что возможно будующие моды будут "строиться" на этой сортировке и их возможно вам придётся переделывать.

[Dr.Freddy]

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

 

Anna, мы тут мозгуем, как бы избавиться от потерь в скорости при сортировке по post_date... Я думаю, без крайней нужды можно оставить так.

[DJ_KISSLOTNIY]

когда ж финал-то будет?

[Dr.Freddy]

Я погонял форум с двойной сортировкой. Потестил вывод темы с sort и без, разница, если она вообще есть, минимальна. И не стал заморачиваться.

 

В общем, я думаю, имеет смысл, если у вас 50+ онлайн. Если кому-то это надо — доработаю.

 

Что до мода, я бы ещё добавил апдейт логов модератора, по-моему этого нету.

[DJ_KISSLOTNIY]

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

[Anna]

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

 

Dr.Freddy - про модераторов это я что-то не подумала. Верно. Надо бы добавить. В ближайшее время сделаю.[1124349027:1124350537]Сделала добавление в модераторский лог:

  //log
 $this->moderate_log("Split post: Master #{$this->pids[0]}, Slave #{$slave_pid}");

[Dr.Freddy]

Anna, все нормально работает. Выкладывай.

[Anna]

Выкладываю...

Разделение ПОСТА

 

все вопросы по поддержке этого мода - прошу в ту тему.

Большое спасибо, Dr.Freddy, за помощь!!

[Dr.Freddy]

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

 

Проблема по непонятным мне причинам решается заменой на $DB->do_update и $DB->do_insert соответственно. Странно, ведь в итоге тот же самый запрос подается... странно. Никто не знает почему так?

<{POST_SNAPBACK}>

Случайно вспомнил про старый вопрос, ибо сам столкнулся Если топикстартеру или кому-нибудь ещё нужен ответ — в do_update и do_insert при компиляции одинарные кавычки меняются на свой «безопасный» аналог — слеш с кавычкой, вот так:

$row[$field] = preg_replace( "/'/", "\\'", $row[$field] );

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