Отдельная таблица количества просмотров в Symfony - PullRequest
Новая
       5

Отдельная таблица количества просмотров в Symfony

0 голосов
/ 01 марта 2012

Как я могу использовать две разные таблицы для одной сущности в Symfony?

У меня есть сущность, которая называет "Article", которая представляет статью блога.
Она состоит из следующих свойств:

  • ID статьи
  • Заголовок
  • Автор
  • Текст
  • Дата
  • Просмотры

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

1 Ответ

1 голос
/ 05 марта 2012

Вы можете иметь таблицу article_views с article_id в качестве FK и счетчика посещений.

Вы обновляете его «на лету» с помощью Propel и symfony 1.4 с помощью однорангового метода в своем одноранговом классе при каждом посещении, указывая идентификатор статьи и соединение. 

public static function incrementVisits($id, PropelPDO $con = null)
{
  $con = (is_null($con)) 
         ? Propel::getConnection(self::DATABASE_NAME, Propel::CONNECTION_WRITE)
         : $con;

  $sql = sprintf('UPDATE %s SET %s = %s + 1 WHERE %s = %d', 
                  self::TABLE_NAME, self::VIEWS, self::VIEWS,
                  self::ARTICLE_ID, $id);

  $stmt = $con->prepare($sql);
  return $stmt->execute();
}

Вы можете заключить этот логин в методе в статье: 

public function incrementViews(PropelPDO $con = null)
{
  return ArticleView::incrementVisits($this->getId(), $con);
}

Тогда вы можете реализовать что-то подобное в методе из Article: 

public function getViews(PropelPDO $con = null)
{
  return $this->getArticleView($con)->getViews();
}

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

Эта опция сделает загрузку запросов UPDATE более предсказуемой, но добавит некоторую задержку.

Надеюсь, это поможет. Я предполагаю, что кеш таблиц, на который вы ссылаетесь, является кешем SELECT в MySQL.

...