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