100 sats \ 5 replies \ @WeAreAllSatoshi 3 Apr \ parent \ on: Perpetual Edits? meta
Also, @ek is gonna blow up the DB with his edits ;)
write
preview
0 sats \ 3 replies \ @k00b 3 Apr
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
21 sats \ 2 replies \ @k00b 3 Apr freebie
Yet another approach I think that might be the goldilocks (no need for a compound primary key on "Item") is the history table pattern1:
  • 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

Footnotes

  1. https://www.reddit.com/r/PostgreSQL/comments/kt1agc/what_is_the_best_way_of_implementing/ ↩
reply
0 sats \ 1 reply \ @nym 3 Apr
What do you think about allowing reposting of old good posts, but at a considerable markup to make the repost?
reply
6 sats \ 0 replies \ @k00b 3 Apr
I'm always interested in increasing evergreenness of old content, but I'm not sure how to do it yet.
reply
0 sats \ 0 replies \ @ek 3 Apr
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