Добавить showUserComments() и countUserComments() - Предложения и пожелания

Для полноценной интеграции с другими компонентами, очень не хватает:

Возможно появление в ближайшей версии?

С первым методом вообще никаких проблем нет - могу добавить хоть прямо сейчас.

Что касается второго, что возвращать-то в нем? Список комментариев в таком же виде, как обычный список комментариев? С разбивкой на страницы или без нее? Разрешать ли при этом кнопки ответа, цитирования? В общем тут нужно сначала обсудить этот момент. В целом я не против расширения API компонента, но нужно оговорить, что именно мы расширяем и как используем.

С первым методом вообще никаких проблем нет - могу добавить хоть прямо сейчас.

Вот поэтому и удивился, что все практически есть, а в API нет.
Сейчас не надо, кому надо сами сделали, а в следующую версию было бы неплохо

Что касается второго, что возвращать-то в нем?

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

Еще вот забыл:
JComments::showOwnerComments($userID = null, $object_group = 'com_content');
- вывод всех комментариев к объектам владельцем (автором) которых этот юзер. Если $userID нет - то к активному в сессии, если это не гость. Вывод, как и для showUserComments и со ссылкой на объект (в плагинах даже все методы для этого уже есть).
Возможно, что showOwner и showUser можно и совместить.

Спасибо. Заранее спасибо.

Вот поэтому и удивился, что все практически есть, а в API нет.

видно никому не нужно было, уж что-что, а API я всегда готов расширить...

Сейчас не надо, кому надо сами сделали, а в следующую версию было бы неплохо

будет...

В основном это нужно для администрирования комментариев пользователем на своей странице. По этому, все правильно сказано, нужен список комментариев не деревом, с разбивкой на страницы, без ответа и цитирования, но с редактированием и удалением.

угу, понятно

Что же касается showOwnerComments - это будет по-позже, дело в том, что в текущей реализации, для определения идентификатора пользователя, который является владельцем объекта нужно делать запрос к БД, а это излишняя нагрузка. В следующей версии я частично решу эту проблему, и вот уже тогда реализация такого метода будет намного проще.

для определения идентификатора пользователя, который является владельцем объекта нужно делать запрос к БД, а это излишняя нагрузка. В следующей версии я частично решу эту проблему, и вот уже тогда реализация такого метода будет намного проще.

Понятно. Спасибо. Сейчас с getObjectOwner($id) действительно нужно генерить тучу запросов к БД. Проще получить через плагин JComments для компонента список id, link и title, автором которых userid, но для этого что-то типа function getOwnerObjects($userid) не хватает в модели плагинов.

Проще получить через плагин JComments для компонента список id, link и title, автором которых userid

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

проще добавить таблицу объектов, и помещать туда эти данные единоразово, при добавлении первого комментария к объекту, а дальше, возможно, обновлять (хотя владельцы редко меняются)

С OwnerObjects через плагин добавляется всего один запрос к БД для получения заранее актуальных данных из компонента в JComments по id не зависящему от обоих компонентов. А хранение избыточной чужой статики в собственных таблицах JComments ведет к нарушению нормализации для реляционной БД, возникает потенциальная засада появления логических ошибок: в компоненте может измениться не только владелец, заголовок, но и способ формирования линков (при абгрейте, например). Это убивает весь ощутимый выигрыш от оптимизации. Поэтому по сравнению с потерей прозрачности модели данных один запрос к БД это практически ничто.
Текущий подход с моделью плагинов очень правильный, красивый, прозрачный и расширяемый.
Все это имно разумеется, хозяин - барин  В любом случае заранее спасибо.

Текущий подход с моделью плагинов очень правильный, красивый, прозрачный и расширяемый.

а я не собираюсь убирать плагины, или сохранять ссылки, я просто хочу кэшировать эту информацию в БД, добавили комментарий - вызвали getObjectTitle, getObjectOwner - сохранили их значения в таблицу jos_jcomments_objects. При добавлении комментария - обновили эту информацию.

В чем выигрыш? Ну вот нужно нам в административной панели показать список комментариев и названия объектов - сейчас выполняем N запросов к БД, а там это все построится одним. Сейчас в административной панели нельзя реализовать сортировку по заголовку комментируемого объекта - а если ввести такую таблицу - можно будет. Нужно показать в модуле список комментируемых объектов с заголовками - опять, примерно те же проблемы. Когда речь идет об однородной выборке (по одному компоненту), я планировал это частично решить методом плагина getTitles, но если данные разнородные - уже проблема. А вот таблица объектов - ситуацию спасет.

А вот таблица объектов - ситуацию спасет.

Теперь понял, так будет красиво. Спасибо.

(офтоп, но навеянный этой темой)
сделать в админке кнопку "Пересчитать ФСЁ". которая бы запускала процесс перепроверки целостности и правильности всех данных JComments. Вдруг где плагины не отработали по юзерам или ещё чего (ты ж в будущем планируешь количество комментариев юзера считать - туда же).

Но в этом решении есть пока один не решенный вопрос - как с наименьшими затратами ресурсов сформировать эту таблицу на сайтах, где уже есть тысячи комментариев. Я знаю сайты, где таблица комментариев содержит по 400-500 тысяч записей (был сильно удивлен, когда мне об этом сказали, и даже не поверил, пока не показали сайты).

Варианта в принципе всего 3:
1. Сделать некую функцию обновления, но ее надо делать на AJAX, с разбивкой на куски, иначе будет большая нагрузка.
2. Формировать/обновлять таблицу при добавлении комментариев, в выборке данных добавляем left join, и если по факту заголовок таблицы или владелец пустые - вызывать явно плагин.
3. Формировать/обновлять таблицу при добавлении комментариев (и параллельно добрасывать в нее объекты (порционно), к которым есть комментарии, но нет еще в таблице).

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

1. При установке компонент создает таблицу объектов
2. При добавлении новых комментариев мы начинаем заполнять/обновлять эту таблицу
3. В таблице настроек добавляется некий параметр (ну что-то типа objects_table_ready), который изначально 0
4. При каждой операции добавления комментария, выбираем 5-10 объектов, для которых есть комментарии, но нет еще объекта в таблице, и заполняем таблицу объектов.
5. Как только объектов, к которым есть комментарии, но нет в таблице не оказалось, устанавливаем objects_table_ready в 1.

И вот если согласно таблице настроек objects_table_ready = 1, то в модели, при выборке комментариев, мы добавляем еще один join В модель и по этому-же параметру, отключаем чтение заголовков посредством плагинов.

Т.е. идея третьего метода, чтобы растянуть процедуру обновления таблицы по времени, не сильно увеличив нагрузку на сервер, и по завершении, сразу перестать использовать метод getObjectTitle при чтении данных.

Если делать 3-им способом, то лучше 4 и 5 пункт вынести в отдельный процесс - скрипт, с возможностью периодического запуска его кроном с регулировкой по limit, для тех у кого записей много, а не привязывать его к добавлению комментария. И код прозрачнее и прогноз по времени переноса и выключить и удалить это можно по завершении просто...

PhocaGallery при обработке пачки фотографий запускает их запуск по одной и обновляет страницу на каждую итерацию.
phpBB3 при создании поискового индекса обрабатывает посты пачками штук по 500.
Насколько я понимаю, там не АЯКС, а всё классическими средствами.

А 500 тысяч комментариев - это конечно жесть!

скрипт, с возможностью периодического запуска его кроном

как показывает практика 80% пользователей компонента вообще не знакомы с PHP, а уж поверить в то, то они смогут добавить вызов скрипта в cron, тем более для разовой операции - больше проблем будет, чем пользы.

phpBB3 при создании поискового индекса обрабатывает посты пачками штук по 500.

если мы будем по 100 объектов создавать, то надо будет делать по 200 запросов (сейчас плагины содержат разные методы для получения заголовка и идентификатора владельца объекта, и это кстати мысль, переделать плагины, много, да все-таки наверно стоит переделать).

А 500 тысяч комментариев - это конечно жесть!

да, там порядка 120 тыс статей и что-то около 40 тыс. пользователей... вот там и возникли проблемы с фильтрами по пользователям и объектам в административной панели - страница просто не грузилась, пришлось показывать фильтры только если записей до 100, а больше - уже через быстрый поиск.

как показывает практика 80% пользователей компонента вообще не знакомы с PHP, а уж поверить в то, то они смогут добавить вызов скрипта в cron, тем более для разовой операции - больше проблем будет, чем пользы.

Всем не надо, только тем у кого 500 тыс. Остальные из админки ручками по кнопке "Пересчитать ФСЁ" (с) Darkick, несколько раз, пока objects_table_ready не включится.

разные методы для получения заголовка и идентификатора владельца объекта

по 300. Еще и линки.

300. Еще и линки.

а вот это вопрос, я не вижу смысла хранить в таблице ссылки (разве что их non-SEF варианты), ибо ссылки имеют свойство довольно часто меняться...

а вот это вопрос, я не вижу смысла хранить в таблице ссылки (разве что их non-SEF варианты), ибо ссылки имеют свойство довольно часто меняться...

А тогда возникают плюс getObjectLink($id) в количестве вывода числа комментариев на странице (заголовок без гиперссылки - пустое место) и собственно ничего не меняется в производительности, кроме возможности сортировки по заголовкам. Или если хранить линки, то куча проблем после абдейта. Тогда уж getOwnerObjects($userid) и getItemsObjects($ids) с $limitstart по странице вывода, а сортировку и по id можно делать. Тоже самое и получается по производительности, максимально два запроса плюc, не зависимо от количество выводимых записей. Плюс заголовок можно получить и показать хинтом при задержке на id курсором, где надо.

Или если хранить линки, то куча проблем после абдейта

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

а сортировку и по id можно делать.

хм, я себе представляю процесс поиска нужного материала посредством сортировки по id...

Тоже самое и получается по производительности, максимально два запроса плюc, не зависимо от количество выводимых записей.

Не тоже самое, если мы храним заголовки и владельцев, то для вывода нужны только ссылки, итого 2 запроса - выборка данных и получение ссылок. Если будем хранить еще ссылки, то в принципе укладываемся в один запрос при выборке, и до 4х лишних запросов при сохранении в текущей реализации плагинов (выборка заголовка, выборка Itemid, выборка owner и возможно выборка категории - для некоторых компонентов еще категория нужна) и потенциально до 2-3 в если оптимизировать плагины (объединяем выборку заголовка, владельца и категории и остается еще Itemid).

хм, я себе представляю процесс поиска нужного материала посредством сортировки по id...

А зачем нужно компоненту комментариев искать по заголовкам других компонентов? Так из него CCK скоро вырастит. Так еще таги чужие захочется видеть и пр. А для админ части достаточно фильтра по object_id и вывода заголовка по конкретно этому object_id по запросу.

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

А если мы ничего не храним, то нужен один запрос для выборки id, title и link (сочиняем в плагине) записей по owner или по id из таблицы компонента, через методы его плагина и еще один - выбор комментариев из JComments по полученным object_id. И того тоже 2. Даже если и 3-4. Но все это при полной прозрачности модели данных и онлайн валидности данных за счет нормализованной структуры БД.

С таблицей же объектов получаем большую засаду в привязке момента ее обновления.
Если обновлять при добавлении комментария, то не известно сколько времени пройдет, между изменениями в компоненте и обновлением таблицы объектов, если такое случиться. Обновление при просмотре - генерировать без конца бестолковую загрузку, еще хуже. Плюс мусор от удаленных в компонентах записей. Если кто-то полезет sql скриптом что-то в данных компонента исправлять, то поимеет дополнительный геморрой с проделыванием тоже самого и в таблице объектов.
И все только потому, что не нормализована структура данных БД. Зачем?

А зачем нужно компоненту комментариев искать по заголовкам других компонентов? Так из него CCK скоро вырастит. Так еще таги чужие захочется видеть и пр. А для админ части достаточно фильтра по object_id и вывода заголовка по конкретно этому object_id по запросу.

В списке комментариев мы показываем еще и объекты, к которым они оставлены, фильтровать или просто искать, по имени объекта без такой таблицы - никак. А это периодически требуется - найти комментарии для конкретной статьи. Ну не записывать же на бумажку ее ID? Если материалов тысячи - никаким выпадающим списком, мы объекты не покажем. А вот надо... Это очень популярный вопрос от буржуев...

А если мы ничего не храним, то нужен один запрос для выборки id, title и link (сочиняем в плагине) записей по owner или по id из таблицы компонента, через методы его плагина и еще один - выбор комментариев из JComments по полученным object_id. И того тоже 2. Даже если и 3-4. Но все это при полной прозрачности модели данных и онлайн валидности данных за счет нормализованной структуры БД.

если мы говорим о странице комментариев для объекта - да, всего 3 дополнительных запроса, а если о модуле, выводящем список прокомментированных объектов с количеством комментариев (к примеру), то сразу умножаем эти 3-4 на количество объектов... И выводить список из 10 последних, прокомментированных объектов (из разных компонентов) посредством 11 запросов - это перебор...

А есть и другое применение - генерация полной RSS-ленты. Она строится по последним комментариям, без фильтров по объектам, и нужно тоже доставать заголовок объекта, строить на него ссылку.

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

Если обновлять при добавлении комментария, то не известно сколько времени пройдет, между изменениями в компоненте и обновлением таблицы объектов, если такое случиться.

да, есть такая избыточность, но есть мнение, что объекты меняются все-таки не так часто, как добавляются комментарии... Можно точно так же говорить о том, что вот включено кэширование, ссылки сформировали, контент закэшировался, тут вдруг SEF поменяли, а ссылки старые - все, ужас.

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

а он и сейчас есть - только для com_content реализовано удаление комментариев, при удалении материала, а все остальное - повиснет в базе... ну нет в Joomla никакого разумного механизма на текущий момент.

Если кто-то полезет sql скриптом что-то в данных компонента исправлять, то поимеет дополнительный геморрой с проделыванием тоже самого и в таблице объектов.

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

И все только потому, что не нормализована структура данных БД. Зачем?

Чтобы одним запросом получать списки:
1. Список комментариев с названиями объектов, владельцем объекта, ссылкой (в модуле, или допустим в списке комментариев пользователя - и очень часто будут к разнородным объектам не из одного компонента)
2. Список часто комментируемых объектов

И я по-прежнему не очень понимаю, что вам конкретно не нравится в данном варианте-то? Что потенциально данные могут быть чуть-чуть устаревшими? А то, что в текущей реализации, если компонент используется (допустим) для 3 компонентов (статьи, каталог, фотогалерея), и нужно вывести просто общую RSS-ленту, то мы будем делать 1 запрос на выборку данных (списка комментариев), затем уже на уровне кода, выбирать списки объектов каждого типа, вызывать для них плагин, по полученным данным обратно в массив комментариев проставлять имя объекта и ссылку. Вместо того, чтобы выполнить всего 1 запрос?

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

И я по-прежнему не очень понимаю, что вам конкретно не нравится в данном варианте-то? Что потенциально данные могут быть чуть-чуть устаревшими?

Да и при этом неопределенно долгое время. Например. Написали статью. Через минуту получили комментарий "поправь пожалуйста ошибку в заголовке". Через 1 минуту поправили. Все, комментариев может больше вообще никогда не быть, а в ту же RSS будет долго и упорно идти старый заголовок. Ничего себе чуть-чуть устаревшие получились...

Вместо того, чтобы выполнить всего 1 запрос?

Нет же, я совсем не против 1 запроса. Просто этот же один запрос можно делать не к таблице объектов, а непосредственно к таблице компонента через метод его плагина. Согласен, что JComments может и должен использоваться для комментариев n компонентов и будет не 1, а n запросов. Ну 5, 10, даже 20, но не 1500, как в том же К2... Это не страшно. В остальном все абсолютно одинаково. Но зато не будет JComments агрегировать данные полей других компонентов, и не втянет в себя из n компонентов по m записей c каждого. Не думаю, что те, кто с 120тыс статей не будут сильно рады такому техническому распуханию и постоянной борьбе с чуть-чуть устаревшими данными...

ну нет в Joomla никакого разумного механизма на текущий момент.

Не спорю, что правда, то правда. Но это совсем не повод плодить мусор в записях

Да и при этом неопределенно долгое время. Например. Написали статью. Через минуту получили комментарий "поправь пожалуйста ошибку в заголовке". Через 1 минуту поправили. Все, комментариев может больше вообще никогда не быть, а в ту же RSS будет долго и упорно идти старый заголовок.

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

Согласен, что JComments может и должен использоваться для комментариев n компонентов и будет не 1, а n запросов. Ну 5, 10, даже 20, но не 1500, как в том же К2... Это не страшно.

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

Давай считать реальную ситуацию, есть сайт на котором комментарии используются в:
1. Материалах
2. Галерее изображений
3. Файловом архиве
4. Каталоге
5. Профилях пользователей

Итого, имеем 5 разных компонентов (но не источников, так как галерея (PhocaGallery) и файловый архив (PhocaDownloads) позволяет комментировать категории и сами файлы). Таким образом у нас 7 разных источников объектов для комментариев. И это простой еще случай, в Music Collections комментировать можно 6 сущностей.

Итак, чтобы сформировать RSS ленту, для такого набора источников нам нужно:

1. Выполнить на получение списка комментариев (1 запрос)
2. Сформировать 7 списков идентификаторов для каждого из 7 источников
3. Получить данные о заголовке и ссылке на объект (14 запросов - по одному на каждый источник и еще одному на Itemid для источника).
4. Пройтись по массиву, полученному на шаге 1 и заполнить его данными полученными на шаге 2.

Итого, для построения RSS ленты требуется 15 запросов. При этом, 7 запросов, будут содержать в себе конструкцию id in (1,2,3), которая при возрастании количества элементов, не так уж и быстро будет работать. Ну представь, что у нас реально первые 99 комментариев оставлены в материалах, и 1 в галерее. Итого, в запросе на выборку данных по материалам, мы получим сет из 99 значений. Красотень... Я не думаю, что план запроса кого-то порадует.

А если у нас есть магическая табличка... То мы выполняем всего 1 запрос - прямая связка по индексному полю, и дальше при отображении для ссылок вызываем JRoute, чтобы построить SEF-ccылку. И все...

Теперь, вернемся к вопросу актуальности данных. Вопрос, конечно серьезный, но ведь есть вполне красивое решение. Причем, на уровне все тех же плагинов. Мы добавляем в плагины еще один метод, назовем его для условности - processAction, задачей которого будет, взять из параметров запроса идентификатор объекта и обновить этот объект в таблице объектов.

Далее, в системном плагине мы смотрим какой компонент вызывается, если у нас есть для него плагин - берем плагин, и дергаем этот метод. Метод сам смотрит - что за действие выполняется, и если это сохранение - обновляем объект, если это удаление - удаляем. Да, есть в данном подходе некоторая избыточность - метод будет вызываться при всех действиях. В этом смысле, лучше вызывать это только для действий в административной панели.

Этот функционал, можно вынести элементарно в настройки плагина - не использовать, использовать для всего сайта, использовать только в административной панели.

А для еще более экономного расходования ресурсов - мы можем создать отдельные события, на изменение/удаление объекта, которые бы вызывались компонентами, а мы по этим событиям - обновляли бы таблицу, или же удаляли комментарии. Все равно так или иначе подобный механизм (оповещения комментариев об удалении объекта комментариев) нужен.

В конечном счете, можно вообще рассматривать данную таблицу, как некий слой кэширования, но не файловый (в Joomla он вообще не управляемый), а с использованием БД. Точно так же, как некая краткая информация об объектах комментирования, можно еще там же хранить счетчики комментариев (опубликованных, неопубликованных), и т.д. Если же этот слой выключен - все будет работать так же, как будто его нет - если выборку данных делать через left join, а на пост-обработке в случае пустых значений в object_title вызывать плагины - то то, на то и выйдет. Зато если включить - в большинстве случаев будет прирост производительности.

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

Если в реальности, то зачем нужна реализация ленты RSS комментариев, не привязанных к конкретному компоненту или его объекту, а только к самому JComments. В чем ее практическая ценность? В конце концов можно заменить ее на n-е количество тематически привязанных лент. А в этом случае выборка из БД в рамках одной ленты уже будет только к одному компоненту (или ее объекту), а не к 7-и и нет никаких 14 запросов в рамках одного цикла. Тоже самое и разумное ограничение и по количеству записей выдаваемых в одном ленте можно сделать.

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

Тогда нужно из таблицы объектов удалять старые по дате записи, иначе вспухнет. Все таки нужно четко определиться кэш это или агрегатор. Это разные по сути вещи.

Подводя некий итог: сама по себе таблица объектов решение полезное и красивое, как академическое. При практической реализации возникает ряд проблем, решать которые придется костылями, и в поддержании актуальности данных в таблице и в методах интеграции в другие компоненты. При этом предполагается выигрыш производительности над другими решениями максимум в 2-3 раза и в отдельных случаях. Решаются проблемы "быстрого вывода", но серьезно утяжеляя модель данных и код.

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

Если в реальности, то зачем нужна реализация ленты RSS комментариев, не привязанных к конкретному компоненту или его объекту, а только к самому JComments. В чем ее практическая ценность?

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

И общая лента, это одно из применений. Другое применение - это список последних комментариев в модуле, список наиболее комментируемых объектов и т.д. Так же таблица (если хранить количество комментариев, что не сложно) даст выигрыш в получении количества для объекта (выборка значения в конечном счете быстрее count).

Тогда нужно из таблицы объектов удалять старые по дате записи, иначе вспухнет. Все таки нужно четко определиться кэш это или агрегатор. Это разные по сути вещи.

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

Подводя некий итог: сама по себе таблица объектов решение полезное и красивое, как академическое. При практической реализации возникает ряд проблем, решать которые придется костылями, и в поддержании актуальности данных в таблице и в методах интеграции в другие компоненты. При этом предполагается выигрыш производительности над другими решениями максимум в 2-3 раза и в отдельных случаях.

Ну наличие костылей в принципе обусловлено несовершенством существующего Joomla API и отсутствия единого стандарта проектирования расширений. Но со временем, я думаю это будет исправлено. Вон, раньше и плагины нельзя было в одном пакете с компонентом ставить...

Решаются проблемы "быстрого вывода", но серьезно утяжеляя модель данных и код.

вот если честно, я не вижу утяжеления модели данных, серьезно... как, впрочем, и кода - сейчас в коде стоят вызовы плагинов, при появлении таблицы - добавится 1 join и вызов тех же самых плагинов (либо принудительный согласно настроек компонента, либо условный, если из выборки не пришли необходимые данные). По сути я не вижу никаких проблем с понятностью структуры данных и алгоритмов.

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

мне все 3 года разработки компонента и не хватает серьезных обсуждений...

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

И общая лента, это одно из применений....Так же таблица (если хранить количество комментариев, что не сложно)

Есть такой полезный анекдот: когда мужики строили в деревне баню, то не могли никак решить строгать пологи или нет. Если будут гладкие, то будет скользко, если не строганые, то будут занозы. Дошло до кулачных сор. Тогда обратились к местному аксакалу-еврею. Через тройку дней аксакал вынес решение: строгать, но с одной стороны и класть струганной поверхностью вниз. Это я все к тому, что  можно использовать положительные стороны обоих методов. Как такое предложение?:

Использовать статистический алгоритм формирования таблицы объектов. Основной принцип: в ней будут всегда несколько сотен только последних комментируемых объектов и записи рекордсмены по заданным параметрам в нужном количестве. Буквально, создается таблица объектов и обновляется по записи (и возможно по просмотру) комментария, как было предложено. Но таблица используется исключительно, как кэш для вывода лент, списков последних комментариев и пр., где действительно желательно иметь 100-500 последних активных оъектов. Удаление не нужных записей - при добавлении и обновлении записей. Критерий ненужности задавать в параметрах компонента. Это может быть и дата последнего комментария и минимальное число комментариев и количество прочтений и все, что в ней можно еще придумать сохранить. Тогда легко сделать заполнение кэша при первом включении или при необходимости за раз. Таким образом решается проблема лент и быстрый доступ к активным заголовкам и в тоже время избавляемся от вечного хранения статистически не активного хлама.

С другой стороны, для вывода в привязке к объекту компонента используется прямой доступ через плагин. Или может даже с предварительным кэшировнием по последнему просмотру в этой же таблице.

Что если так? Есть засады?

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

Можно. Как только обнаружу ветку и разберусь о чем речь, обещаю обязательно тоже подтянуться. Пока не разбирался, в чем проблема была до сих пор, вывод 0 уровня дерева и вывод следующего уровня ветки по требованию вроде довольно избитая тема?

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

Во-первых 99% пользователей не будут указывать никаких параметров и система либо вообще не будет работать, либо будет работать в полном режиме.

Во-вторых, давай смотреть на задачу шире, списков последних комментариев может быть масса (просто последние комментарии, последние комментарии для конкретного компонента, последние комментарии конкретного пользователя, последние неопубликованные комментарии к объекту или какого-то пользователя). И все эти списки должны строится просто и быстро. И наличие постоянной таблицы решает все эти задачи весьма оперативно.

В принципе, можно добавить в таблицу время последнего комментария к таблице (т.е. время, когда мы потенциально последний раз могли эту запись обновить), и записи старше чем N-дней удалять. Тогда при выводе комментариев к такой записи будет использован плагин, а если добавится комментарий - то мы ее воссоздадим. По умолчанию можно поставить хоть год (и в 90% случаев это будет оптимально), но если проект предполагает периодическое изменение заголовков, или же, на случай смены SEF, можно предусмотреть кнопку Очистить кэш объектов.

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

Пока не разбирался, в чем проблема была до сих пор, вывод 0 уровня дерева и вывод следующего уровня ветки по требованию вроде довольно избитая тема?

Алгоритмически, с точки зрения выборки данных, особых проблем нет, тем более что в таблице комментариев с версии 2.2 введены 2 полезных поля - level и path, т.е. никаких проблем выбрать всех детей одной ветки, или только прямых наследников - нет. Если проблема с точки зрения шаблона. С одной стороны, очень не хочется в очередной раз менять шаблон, и создавать людям проблемы при обновлении. С другой стороны, текущая реализация шаблона имеет 2 режима - плоский список, и древовидный, причем древовидный целиком, и без рекурсии. Выбрать данные 1-го уровня - проблем нет, а вот сформировать отображение одного уровня не получается (по крайней мере без костылей). На текущий момент я подумываю над тем, что просто в шаблон добавить еще один файл, именно для такого динамического отображения. Кроме того, вот сейчас (для плоского списка), когда пользователь переходит по ссылке, я на уровне JavaSript вычисляю на какой странице должен быть этот комментарий, и автоматически ее открываю. Если у нас дерево изначально свернуто, а пользователь перешел по ссылке на какой-то комментарий, надо по идее автоматически развернуть всю ветку... Для этого пока тоже никакого механизма нет. В общем я на днях сделаю отдельный топик, и там опишу ситуацию - т.е. что хотелось бы реализовать, и какие проблемы на текущий момент я вижу.

Во-первых 99% пользователей не будут указывать никаких параметров и система либо вообще не будет работать, либо будет работать в полном режиме.

По умолчанию будут сразу заданы, а менять и в какую сторону - это пусть каждый сам решит. Да и параметры не в прямую, больше из модулей - топ-N, количество в ленте и пр. Естественно с нижними и верхними порогами.

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

Не вижу противоречий. Список по нужному критерию сортировки вывода определяется необходимостью самого вывода. Число комбинаций конечно. Нет вывода значит и хранить не надо. Если вывод по конкретному критерию случился - положили полученный топ-N в эту таблицу. Долго не изменялся - в топку. Идея как раз хранить не вечно и все, а только статистически активные записи. Ни что не мешает хранить N записей рекордсменов по каждому критерию. Дальше только удалять ушедших за минимальное количество.

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

Вот, я о том же. Даже шире. Только не год, лучше уж полный штамп. Возможно и дату последнего вывода (не в ленту и топы) тоже нужно будет (все равно счетчик просмотров инкрементировать). Еще и топ-N рекордсменов туда же положить, после первого же вывода. И по идее почти все проблемы решены, как при старте, так и в полете.

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

Немного яснее. Уже есть идеи . Обязательно приду.

Кстати, вот сегодня интересная ситуация - у пользователя 35 тысяч комментариев в JomComment, я немного переделал функцию импорта, теперь мы такие объемы поднимаем без проблем - импорт разбит на шаги, используется AJAX, в общем проблем тут как бы нет. А вот дальше, когда нам нужно в административной панели открыть список комментариев, возникает пара проблем.

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


Чтобы получить список используемых в комментариях языков, аналогичный запрос:


И еще похожий запрос есть для оценки количества пользователей, чтобы показать фильтр по пользователям (если их меньше 100), но тут все равно запрос выполнять нужно.

Вот эти запросы, с очень большой вероятностью, на один типовой сеанс работы с административной панели (10-15 минут), возвращают одни и те же данные. И в принципе ничего не мешает их закэшировать. Но проблема в том, что даже при наличии индексов, они выполняются порядка 40 секунд... Что мягко говоря не приемлемо для решаемой задачи.

Отказаться от фильтров - ну не решение, а вот таблица бы ситуацию спасла. Тем более, эти 35 тысяч комментариев оставлены к 3287 объектам.

неужели при наличии индексов уходит 40 секунд на такую выборку? мне казалось такие вещи должны отрабатывать быстро (надо попробовать...)

неужели при наличии индексов уходит 40 секунд на такую выборку?

Ну вот суммарно эти три запроса у меня на локальном компе именно столько и отрабатывали, почему - не знаю, вечером проведу эксперименты дома и на сервере. Но вообще, тут дело такое - здесь у нас 3 тыс. объектов и 11 комментариев (в среднем) к объекту, и есть некоторые тормоза. А ведь есть сайты, где не 35 тысяч, а 350 тысяч комментариев... и каждый раз, чтобы просто получить фильтр по компонентам делать distinct по всей базе комментариев, как бы не очень эффективно.