Как сохранить все пользовательские активности на сайте? - PullRequest
1 голос
/ 30 марта 2012

У меня есть сборка веб-приложения на Django + Python, которая взаимодействует с веб-сервисами (написано на JAVA ).

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


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

Like Если пользователь опубликовал новую статью, то новая строка создается в таблице статей веб-службами и рядом, мне нужно добавить новую строку в таблицу журнала , что-то вроде " Пользователь: Раман опубликовал новую статью (с ID, названием и т. д.) "

Я должен сделать это для всех объектов в моей базе данных, таких как «Статья», «Медиа», «Комментарии» и т. Д.


Примечание: я использую PostgreSQL


Так как же лучший способ достичь этого? ?? (Должен ли я сделать это в PostgreSQL ИЛИ JAVA .. ?? .. И как .. ??)

Ответы [ 5 ]

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

Для таблицы аудита в самой БД, посмотрите на Пример аудита триггера PL / pgSQL

Это регистрирует каждую INSERT, UPDATE, DELETE в другую таблицу.

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

Итак, у вас есть UI <-> Web Services <-> DB

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

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

РЕДАКТИРОВАНИЕ: Это все еще означает, что вы создаете схему БД для «журналов» и записываете ее в БД.

Второе РЕДАКТИРОВАНИЕ: Поймать события, достойные журнала, в UI , а затем записать их оттуда, тоже может быть не самой лучшей идеей.Вам придется переписать протоколирование, если вы когда-нибудь решите заменить пользовательский интерфейс или, например, написать альтернативный пользовательский интерфейс для, скажем, мобильных устройств или чего-то еще.

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

Я использовал django-audit-log , и я очень доволен.

Django-audit-log может отслеживать несколько моделей, каждая из которых находится в отдельной таблице. Все эти таблицы довольно унифицированы, поэтому создать представление SQL, отображающее данные для всех моделей, должно быть довольно просто.

Вот что я сделал, чтобы отследить одну модель («Pauza»):

class Pauza(models.Model):
    started      = models.TimeField(null=True, blank=False)
    ended        = models.TimeField(null=True, blank=True)
    #... more fields ...

    audit_log = AuditLog() 

Если вы хотите, чтобы изменения отображались в Django Admin, вы можете создать неуправляемую модель (но это ни в коем случае не требуется):

class PauzaAction(models.Model):

    started      = models.TimeField(null=True, blank=True)
    ended        = models.TimeField(null=True, blank=True)
    #... more fields ...

    # fields added by Audit Trail:
    action_id    = models.PositiveIntegerField(primary_key=True, default=1, blank=True)
    action_user  = models.ForeignKey(User, null=True, blank=True)
    action_date  = models.DateTimeField(null=True, blank=True)
    action_type  = models.CharField(max_length=31, choices=(('I', 'create'), ('U', 'update'), ('D', 'delete'),), null=True, blank=True)
    pauza        = models.ForeignKey(Pauza, db_column='id', on_delete=models.DO_NOTHING, default=0, null=True, blank=True)

    class Meta:
        db_table = 'testapp_pauzaauditlogentry'
        managed = False
        app_label = 'testapp'

Таблица testapp_pauzaauditlogentry автоматически создается django-audit-log, это просто создает модель для отображения данных из нее. Может быть хорошей идеей добавить грубую защиту от несанкционированного доступа:

class PauzaAction(models.Model):

    # ... all like above, plus:

    def save(self, *args, **kwargs):
        raise Exception('Permission Denied')
    def delete(self, *args, **kwargs):
        raise Exception('Permission Denied')

Как я уже сказал, я думаю, вы могли бы создать представление SQL с четырьмя полями action_ и дополнительным полем 'action_model', которое могло бы содержать ссылки varchar на саму модель (может быть, просто исходное имя таблицы).

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

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

https://docs.djangoproject.com/en/dev/topics/signals/

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

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

В вашей журнальной таблице вы можете иметь различные столбцы, в том числе:

  • user_id (пользователь, который выполнил действие)
  • activity_type (тип деятельности,например, view или commented_on)
  • object_id (фактический объект, к которому он относится, например Article или Media)
  • object_type (тип объекта; этоможет использоваться позже, в сочетании с object_id для поиска объекта в базе данных)

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

...