Hi Arun, On 25.08.22, 13:20, "Arun Ram" <arun91i...@gmail.com> wrote: > We have encountered a behavior of versionStorage and versionLabels which I > think is bug. > > *Current behavior:* > > 1. Create a node and make it *versionable* > 2. Now create more than two versions (for example two version is *1.0* > and *1.1* respectively) > 3. Now add label at version 1.0 via *VersionHistory* Object (for example > label is *Label_1.0*) > 4. Now remove the version 1.0 via calling *removeVersion(1.0)* method of > *VersionHistory* object > 5. Now call method *hasVersionLabel(Label_1.0) *of versionHistory . its > now returning true. > > *Expected behaviour:* > > Call to the *hasVersionLabel(Label_1.0)* of *versionHistory* should not > return true because version associated with label does not exist. And > removing the version should remove associated labels.
I agree, the current behaviour is rather unexpected and looks wrong to me. > If we say that *hasVersionLabel(Label_1.0)* of *versionHistory* returning > true is expected behavior because label is not removed. Then call to the > function getVersionByLabel(*Label_1.0) of versionHistory* will throw > VersionException because version does not exist. So the repository goes > into inconsistent state. I think the repository should not get into a state where there is a dangling version label. In my view the implementation of removeVersion() must be changed. > *Solution proposal:* > > One of the solution can be that whenever consumer of versionHistory > removes the version , he should be forced to remove the versionLabel first > by throwing LabelExistException I was trying to find the relevant section in the specification, but did not find something useful. JavaDoc for VersionHistory.removeVersion() gives a hint. The method signature does not mention LabelExistException, but it says about ReferentialIntegrityException: > "if the specified version is currently the target of a REFERENCE property > elsewhere in the repository (not necessarily in this workspace) and the > current Session has read access to that REFERENCE property." This could also cover the version label, because it is in fact a reference property. So, I think one option would be to throw a ReferentialIntegrityException when there is a label on the version to be removed. > Another solution can be we should remove version label whenever user > removes the version. This also sounds reasonable. Did you check the behaviour of classic Jackrabbit? I think it would be good to have consistent behaviour for classic Jackrabbit and Oak. Regards Marcel
