pull down to refresh

Also, @ek is gonna blow up the DB with his edits ;)

Yeah this could be difficult to scale. Depending on how it's implemented it might also require a compound primary key on items because their id alone would no longer identify them.

I haven't looked into the diff approach much, but that'd be minimally invasive by comparison. I just don't have experience with it.

reply

Yet another approach I think that might be the goldilocks (no need for a compound primary key on "Item") is the history table pattern[1]:

  • create an "OldItem" table using inheritance with a foreign key reference to "Item".id
  • on edits, copy the current "Item" to "OldItem" (taking care with primary keys and timestamps) and then edit the "Item" as usual
  1. https://www.reddit.com/r/PostgreSQL/comments/kt1agc/what_is_the_best_way_of_implementing/

reply

What do you think about allowing reposting of old good posts, but at a considerable markup to make the repost?

reply

I'm always interested in increasing evergreenness of old content, but I'm not sure how to do it yet.

reply

We could merge multiple edits in the same time window into a single edit. I think I've seen that on Github but it doesn't always seem to work that way.

or we could add a special case to limit my edits haha

maybe that is premature optimization?

reply