On 10. jan. 2012, at 13.31, ext Oswald Buddenhagen wrote: > On Tue, Jan 10, 2012 at 01:00:42PM +0100, ext João Abecasis wrote: >> It is not appropriate to tag an atomically-replace-previous-version on >> to the close() > > you don't provide any supporting evidence for that pov, though.
Because code that wasn't written to make use of the transactional functionality we're trying to offer could assume that close followed by open is a safe operation. There could be code that opens, writes, closes for each sub-component that goes in the file or something of that sort. With the atomically-replace-previous-version feature, having close commit the transaction means you throw away the old version. You'll be no worse off than not having the feature, but you also won't get the feature that you thought you were using. Furthermore, if we assume that open always starts from a clean slate (empty file, as in Truncate), then open+write+close is even more dangerous... But I guess there you'd just be discarding the open flags... >> and normal clean up that the destructor does. > > that i agree with. > >>> No, whatever this class is, close() without commit() means >>> "rollback". >> >> Right. Keep in mind we are not only saving the new version. We're also >> destroying a previously known good copy. > > uhm, so? without the temp file, open() would already do that. True, but if we are to offer atomic replace previous version I think we can do it properly. That means explicit commits because code has to be written to take advantage of this feature properly. It also means not assuming that arbitrary code magically gets better because of the Transactional flag on open. Cheers, João _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
