Revision History (Modeling)

[cloudiirain]

Looking for some advice on how to implement revision history.

User Story

A user/moderator clicks on a series page. They see that another user has spammed the page with nonsense (or information that is plain wrong). This needs to be reverted, so they click on the revision history and restore a previous version.

An editor just made a chapter to a chapter the translator is not happy about. Translator wants to revert the chapter text.

A moderator wants to view the Recent Changes of everything on the app in one place, in chronological order.

The dumb way of implementing revision history

• For chapter, make a one-to-many relationship to a chapter_history table that contains a json object of the chapter in each moment in time. Can postgresql even store json? If not, the history table needs to contain a field for all of the fields in the main table as well.
• Also repeat this for every model that requires a revision history, such as Series.
• But how would you merge all of these individual revision history tables to display Recent Changes?

  The mongo way (at least, this is how I think people would do it in Mongo)

• Make a table/collection called Model_History
  • fields:
  • timestamp
  • Class of the object stored
  • object_id of the object stored (maybe coulded be a hashed representation???)
  • json snapshot of the object at that point in time
  • Anything else you would want to know (like the user who did the change, etc)
• Model_History would be able to store snapshots from any model (e.g. Series, Chapter, etc)
• Benefits are that it's really easy to generate Recent Changes from this

  But honestly I don't really know how to best approach this

Any pointers? Advice?

[cloudiirain]

Update: Can confirm that postgresql can store json.

[Fuyukai]

I'd do it so the Chapter table is just a table with a single One-to-Many to many history objects ordered by timestamp.

That way, the chapter_history table contains the actual data, and the current chapter revision can be got by looking up the first item of the relationship.

[cloudiirain]

@SunDwarf, that's totally fine -- and do the same things with Series information, etc.?

@scraeling suggested that we store git diffs. I actually think it's easier to store the full body of the text with every revision and compute the diffs if we need them. Database size might be bigger this way, but I'm all for doing the easier thing. ;-;

[Fuyukai]

Well, you have the tradeoff between CPU time and storage there. But the first one can effectively be avoided with a cache, or similar.

[danieltanfh95]

I think I'm going to just nest a page schema within the chapters schema for this.

schema.pageSchema=new mongoose.Schema({
  timestamp:Date,
  hash:String,
  text:String,
  user_id:Number
});

schema.chapterSchema=new mongoose.Schema({
  title:String,
  page:[schema.pageSchema],
  linktype:String,
  link:String
});