Not storing unnecessary versions looks like a feature for me. Imagine a scheduler job that update some pages every night, I would be glad that it does not create new versions when nothing has changed in the end.
Maybe I look at this with a biased vision: I know that having a lot of versions of a document can cause problems (when we move the document for example). If we had not this problem, maybe I would have the same opinion than you. Thanks, 2017-02-08 14:33 GMT+01:00 Thomas Mortagne <[email protected]>: > Hi devs, > > We have a unintended regression in the standard import: if what you > import is identical to what is already in the database (including the > author) it won't add a new version (if you use the default option "Add > a new version to the existing page"). > > What happen in practice is that if you keep calling XWikiDocument#set* > methods with the same data it won't update the metadata or content > dirty flags. This flags are what hibernate store look at to know if it > should add a new version or not. > > You can reproduce the same behavior with a simple script which load a > document, always set the same content and save. You will notice that > the history of that document does not change. > > So the question is do we force metadata dirty to true all the time in > the instance output filter or do we keep this feature (in which case > we should optimize it a bit to not do the useless XWiki#saveDocument > but that's another subject). > > WDYT ? > > It could be seen as a nice feature but in practice my first reaction > was WTF and you often want to be sure the import actually did > something so I'm +1 to force metadata dirty. But I'm +0 to keep the > current behavior if there is a majority for it. > > -- > Thomas Mortagne > -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project
