views:

816

answers:

2

Basically if I do Xdoc.Load(filename), do some changes then do Xdoc.Save(filename) does it only save things that changed such as inserted or removed elements, etc, or does it resave everything?

Depending on the answer I'm thinking of determining whether my app is going to save per-change or save on explicit save and on exit. Also considering whether to write to multiple xml files or just keep everything in one big file. I have no idea how big the one big file would be but I suspect it could potentially be 10's of MBs, so if it's resaving the entire file then I definitely can't be saving every change while keeping one big file.

If it does save the entire file, does anyone have opinions of having a separate xml file for each entity (potentially hundreds) and whether or not it's a good idea?

+7  A: 

It saves the whole file. That is the nature of text based formats. A text file cant overwrite itself without rewriting the unchanged parts.

Josh Einstein
Just a further point; this is doubly true of variable length encodings, such as UTF8 (which is common with xml) - meaning you can't even (robustly) swap a single character without risking corruption.
Marc Gravell
+2  A: 

Yes, saving a document saves the whole document.

What's the use case for the "per change" save? Is it just in case the application crashes? If so, I suggest you save these incremental changes in a temporary directory as small files, but when the user explicitly says to save the file, save it in one big file. (That's easier to copy around etc.) Delete the temporary directory on exit.

I do wonder whether you really need the temporary directory at all though. It sounds like quite a lot of work for little benefit.

Jon Skeet
Right, per-change saves is just in case of crash, power-outage, other exceptional events. It's not a huge deal, nothing really mission-critical, but nice assurance for users that they don't ever (minus corrupted/deleted file/disk) need to worry about re-entering data they've already entered before.Although I wonder whether just saving on a background thread would be sufficient. Saving 27MB of for-loop generated xml took under 2 seconds, which while too long if it's blocking the UI might be ok if it's don in the background. And that's larger than 95% of expected use case data.
Davy8
Yup - just be aware that you'll need to make sure you don't change the data in the UI while you're saving it in the background thread.
Jon Skeet