Как логировать изменения с возможностью откатить?

Question

[SoloMidPlzD]

допустим есть простая схема many-to-many
articles, article_tags, tags

Нужно чтоб каждое изменение логировалось + возможность откатки в 1-3 клика

изменение полей article, и связаних с ней тегов.

Допустим была запись:
article.title = "hello world1", article.body = "Текст записи1", article.published_at = 2016-11-20, article.user_id = 1;
связка article_tags (1,1), (1,2)
Другой пользователь изменил статью и она уже
article.title = "hello world2", article.body = "Текст записи2", article.published_at = 2016-11-20, article.user_id = 3;
связка article_tags (1,1), (1,3), (1,4)

Comments

[Илья Хребет]

Можно подробней?

Answer 1

[UksusoFF]

https://github.com/VentureCraft/revisionable

Answer 2

[Александр Аксентьев]

изменение чего?

Comments

[SoloMidPlzD]

изменение полей article, и связаних с ней тегов

Answer 3

[Евгений Вольф]

Изменения чего Вы хотите логировать? Базы или файлов? Если файлов - то GIT.

Если базы, то миграции или, возможно, Git+миграции.

Если ещё и данных в БД, то бекап БД (если база небольшая, то бекап в GIT).

Comments

[SoloMidPlzD]

изменение полей article, и связаних с ней тегов

[Станислав Почепко]

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

[Евгений Вольф]

Станислав Почепко: я думаю, единственный вменяемый способ в таком раскладе - это либо миграции ларавеля, либо дамп БД без данных (дамп структуры) в GIT-репозиторий. В принципе, если без данных, думаю миграции отлично подойдут.

[Станислав Почепко]

Евгений Вольф: Опять вы не поняли.

Сначало у пользователя было 5 избранных документов, а потом он выбрал 28 избранных. И тут нужна история, что раньше у него было их пять. Или аналогично журнал изменений тегов к статье. Было 1,2,3, 7 а стало 5,3,2,8,9 а потом 4,3. И надо как-то это всё записать в журнал

[Евгений Вольф]

Станислав Почепко: Тогда это уже целиком базу дампить нужно, я думаю, вместе с данными. Можно в репозиторий... Другое логирование я себе едва ли представляю... Хотя, можно конечно конечно, ковырять лог самой БД, но она и так и эдак его ведёт, хочет того пользователь или нет...

Answer 4

[Александр Урих]

Например держать 2 таблицы
currentItem
itemHistory

Перед записью в currentItem его содержимое новой записью в itemHistory
И откатывать так же

Answer 5

[Станислав Почепко]

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

Answer 6

[Степан]

Может, будет удобнее повесить триггер на обновление/изменение таблицы, который будет писать "старые" значения в «таблицу архивных значений»?