Dear FirstSpirit community,
with the following public FirstSpirit ACCESS API method:
getHistory(before, HistoryProvider.EVER_SINCE, HistoryProvider.ALL_REVISIONS, RevisionFilter.RELEASE_FILTER);
all RELEASE revisions on a FirstSpirit store element should be retrieved. This is expected - but the real world shows differences, like here on a pagestore node where:
- not all revisions are delivered
- revisions are given that are not available and visible within the FirstSpirit version historiy in JavaClient
The current result looks like:
[Revision [id=54163, editor=Admin (Admin) [ID=1], state=0, change=1300295439271, comment=server release],
Revision [id=54158, editor=Admin (Admin) [ID=1], state=0, change=1300295410920, comment=server release],
Revision [id=22583, editor=Admin (Admin) [ID=1], state=0, change=1284625893587, comment=server release],
Revision [id=22198, editor=egd8fe (Daniela Ege) [ID=7256393], state=0, change=1282653268373, comment=server release],
Revision [id=18970, editor=Admin (Admin), state=0, change=1273284036916, comment=release],
Revision [id=11314, editor=Admin [ID=1], state=0, change=1228324167078, comment=server release]]
Enclosed a screenshot of the version history of the FirstSpirit JavaClient regarding that node:
What do we do wrong? Or is there a bug?
Dear Community,
the implementation behavior between the FirstSpirit JavaClient version history and the public accessible FirstSpirit API "getHistory()" differs. This is proven in the above comment compared to the screenshot.
Reason for the differences:
(1) The version history dialog in JavaClient just shows all changes directly executed on a FirstSpirit node. In contrast, the "getHistory" ACCESS-API call does collect even changes for a node, that might be provoked implicitly by another one. For example:
- you take a look at the version history of a page store node folder. There, you won't see any release changes executed on one of the child nodes within the FirstSpirit JavaClient version history perspective
- but: FirstSpirit does implicitly change the parent's child list, in case where you release one of the child nodes in case where child and parent have not ever been released before
Here, the "getHistory()" ACCESS-API calls will collect all changes on the parent node while the JavaClient version history dialog won't show them. This situation happens especially on non-leaf FirstSpirit nodes like page/site/media store elements where implicit changes provoked by child elements might be executed.
(2) Additionally, the "getHistory()" ACCESS-API call won't get changes, whose OPERATION value (a BerkeleyDB attribute, see RepoViewer screenshot enclosed) is not set respectively NULL (due to a migration of different FirstSpirit releases in the past). Here, the JavaClient's version history behaves in another way - it collects all explicit changes on the node independent of the operation attribute.
