3 ms·

If you have a db, why not just model it as unsaved data? I.e. all changes get stored to the db, but have a flag of unsaved. If you open up a file and there ar

• mort96 3y ago
  That feels like it requires the data model to be very different? The file format would essentially need to be a list of changes, with a "committed" flag. Like, if someone changes some text in a paragraph, you can't just model that as "this paragraph now contains this new text". You have to model it as "this paragraph used to contain this text, but an uncommitted change changed it to this other text". User deletes an image? You have to still store the image and all the references to it, but with an uncommitted change to delete the image and remove the references to it. And maybe that's a good thing, maybe a git-like system where the history of every change is tracked is what you want. But it certainly doesn't feel like it'd be appropriate for every application and file format.
  • julesnp 3y ago
    You wouldn't necessarily need to track every change, you could just have 2 tables, one which contains the last "saved" version of the document, and one which contains the last modified version of the document. Upon opening after a crash, if there is a more recent modified version, the program will ask if you want to load that version.
    • mixmastamyk 3y ago
      Databases handle all this natively with transactions and WALs. i.e. Don't need to build a Flintstones version yourself. Also binary documents are a lousy fit with git, smashing square peg into round hole makes little sense.