You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Opening this issue to memorialize a brief discussion we had in IRC about adding post updating.
Currently it's not possible to update a Post in place, and there's no concept of revisions that can be compared. Right now, there's a Post model and a File model. Posts have a one-to-many relationship with Files (each Post has one or more Files). My suggestion is that it should be possible to elaborate on this design slightly to add the ability to add updating and history.
First, update the File model:
Add a replaces nullable foreign key column.
Add a checksum nullable column of some sort to contain a checksum (maybe a BLAKE3 checksum, but it doesn't matter).
Add a diff column, as a nullable string.
Wherever we render the Files belonging to a Post, we would filter out any File referenced by another File as replaces. Whatever is left is the Post's current Files.
Updating a Post would mean presenting the contents of each File to edit. When the form is posted to update the Post's Files, it would be necessary to figure out which, if any, Files got their contents changed. You could use a checksum for determining this. For any File whose contents' checksum has changed:
Create a new File.
Associate that new File with the same Post.
Set the new File's replaces to the ID of the old File which it replaces.
Set the new File's contents in the contents column.
Diff the new File's contents against the old, and store that in the diff column.
Calculate the checksum of the new File's contents, and store that in the checksum column.
To show the history for a given Post, iterate over each of its current Files (any File not referenced by another File as replaces). Then for each File:
If the File's replaces column is null, skip and move on to the next File current for the Post.
If the File replaces another File, grab the replaced File's diff.
Repeat the first two steps with the replaced File.
You can just display those diffs somewhere for each File as its history.
Hopefully the above captures the idea well enough. Every bit of it is just an optional suggestion, so don't take any of it too literally.
The text was updated successfully, but these errors were encountered:
Opening this issue to memorialize a brief discussion we had in IRC about adding post updating.
Currently it's not possible to update a Post in place, and there's no concept of revisions that can be compared. Right now, there's a Post model and a File model. Posts have a one-to-many relationship with Files (each Post has one or more Files). My suggestion is that it should be possible to elaborate on this design slightly to add the ability to add updating and history.
First, update the File model:
replaces
nullable foreign key column.checksum
nullable column of some sort to contain a checksum (maybe a BLAKE3 checksum, but it doesn't matter).diff
column, as a nullable string.Wherever we render the Files belonging to a Post, we would filter out any File referenced by another File as
replaces
. Whatever is left is the Post's current Files.Updating a Post would mean presenting the contents of each File to edit. When the form is posted to update the Post's Files, it would be necessary to figure out which, if any, Files got their contents changed. You could use a checksum for determining this. For any File whose contents' checksum has changed:
replaces
to the ID of the old File which it replaces.contents
column.diff
column.To show the history for a given Post, iterate over each of its current Files (any File not referenced by another File as
replaces
). Then for each File:replaces
column isnull
, skip and move on to the next File current for the Post.replaces
another File, grab the replaced File's diff.You can just display those diffs somewhere for each File as its history.
Hopefully the above captures the idea well enough. Every bit of it is just an optional suggestion, so don't take any of it too literally.
The text was updated successfully, but these errors were encountered: