jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Versionable paths
Date Thu, 31 Oct 2013 09:03:19 GMT
hi

if i remember correctly the move case you mentioned below is
covered by the commit hook (see VersionablePathsTest). if there
are cases that don't work properly i would be glad if you could
provide add a test case (patch for the fix is optional).

as far as the location of the versionable path is concerned
i am not convinced that moving it the versions will add any
benefit. my plan was to bind accessibility of the whole
versionhistory associated with a versionable node to the
permissions enforced on that very node in a given workspace. so,
in other words the accessibility may change if the effective
permissions change for that node (by changing the ac content
or by moving around the node or any of it's ancestors).

i guess what you intended to achieve by moving it to the
versions themselves is to version the effective permissions
themselves... but that would not require moving the paths
information to the version but rather copying the complete
effective permissions to the version including all effective
permissions present to the whole subtree that is copied to
the version node. that's IMHO not feasible.

another disadvantage of moving it to the version information
is that you can't determine the accessibility of the version
history node. i had a similar issue when it comes to the
intermediate nodes the make up the structure of the version
storage and didn't find a satisfying solution.

and last:
you are right regarding collisions in the workspace name. but
i would suggest that we just escape the name.

as far as renaming/removing workspace is concerned: renaming is
not supported by JCR afaik. creating new workspace as well as an
existing workspace (once we actually support multi-workspace setup)
could be covered by the corresponding commit hook, couldn't it?

kind regards
angela



On 10/30/13 11:52 PM, "Tobias Bocanegra" <tripod@apache.org> wrote:

>Hi,
>
>oak now has rep:VersionablePaths which record the paths (per
>workspace) of the versionable node.
>
>I think this is wrong to store this on the nt:versionHistory node,
>since a node can be moved in between checkins. so I think it should be
>recorded on the nt:version node.
>
>I also find it dangerous to just use the workspace name as property
>name for the path, as it makes it harder to list the paths, if ever a
>workspace is removed or renamed (not that this is supported). also, it
>does not work with "funny" workspace names, such as: "jcr:uuid" :-)
>
>I suggest the following structure:
>
>/jcr:system/jcr:versionStorage/..../ [nt:versionHistory]
>  /1.0 [nt:version]
>    /rep:versionablePaths
>        + workspace1name "/path/..."
>        + workspace2name "/path/..."
>        + workspace3name "/path/..."
>
>OR a MV value:
>
>/jcr:system/jcr:versionStorage/..../ [nt:versionHistory]
>  /1.0 [nt:version]
>    + rep:versionablePaths [
>           "workspace1name/path/",
>           "workspace2name/path/",
>           "workspace3name/path/"
>       ]
>
>WDYT?
>
>Regards, Toby


Mime
View raw message