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 <thomas.mortagne(a)xwiki.com>om>:
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 (guillaume.delhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the
XWiki.org project