pull down to refresh

263 sats \ 11 replies \ @k00b 3 Apr \ on: Perpetual Edits? meta
We've talked about it a lot and want to do it. Somehow we don't have a github issue yet. I'll make one today.
write
preview
100 sats \ 9 replies \ @WeAreAllSatoshi 3 Apr
I imagine the technical side is very straight forward and simple (like how bio posts are infinitely editable) what’s more vague is the requirements of “when should we allow this?”
reply
107 sats \ 8 replies \ @k00b 3 Apr freebie
It's the inverse!
We always want to allow editing but in a way that's technically nontrivial (and I'd argue still straightforward to the right person).
Technically, we want items to be immutable. Each edit would create a clone of the old, apply its modifications to the clone, and the old version would be kept along with the new so that there's an edit history.
It'd work roughly like the following:
  1. give all items a "cloneBornAt" and "cloneDiedAt" timestamp
    • a new, unedited item would have "cloneBornAt" = null, and "cloneDiedAt" = null
  2. when an item is edited
    • clone it
    • give the old version "cloneDiedAt" = now()
    • give the new version "cloneBornAt" = now() and "cloneDiedAt" = null
    • make the requested edits to the clone
The items we'd display would have "cloneDiedAt" = null, because only the most recent version would have "cloneDiedAt" = null, but the full edit history could be browsed.
Alternatively, we could create a "diff" between subsequent versions and store that for creating the edit history, but immutability is more straightforward imo.
reply
100 sats \ 5 replies \ @WeAreAllSatoshi 3 Apr
Also, @ek is gonna blow up the DB with his edits ;)
reply
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
100 sats \ 1 reply \ @WeAreAllSatoshi 3 Apr
Neat! I didn't realize the goal was to preserve edit history, but that makes sense!
How are deletes handled in this case? All clones are overwritten with deleted by author?
reply
0 sats \ 0 replies \ @k00b 3 Apr
Ah good question! I hadn't considered it.
Yes, I think overwriting all clones is probably the least invasive thing.
reply
0 sats \ 0 replies \ @siggy47 OP 3 Apr
Great!
reply