Hi John, as Thomas mentioned, MK branches are an implementation detail of the micro kernels that cannot (should not) be leveraged on higher level. Your use case might be solvable by access control (so that authors 1 and 2 see different parts of the tree). The query engine honours such ACLs so the corresponding result sets would be different.
In Adobe’s AEM6 the use case you describe has been solved on application-level (i.e. above the JCR API) by creating a complete copy of the tree under edit and merging back after edit (the merge happening on application level again). Best regards Michael On 27 Nov 2014, at 11:12, Thomas Mueller <[email protected]> wrote: > Hi, > > Oak internally branches in some cases, but this is not exposed in the JCR > API (you can not enforce creating a branch). > > Regards, > Thomas > > On 26/11/14 18:56, "John Gretz" <[email protected]> wrote: > >> Hey guys, a newbie Oak question: >> Since there is support for a single workspace only in Oak, is there a >> good mechanism to simulate scenarios like below using branches in Oak? >> The JCR-compliant queries are unaware of Oak MK branches, so is there a >> way to use the Oak's Query to query on a particular branch only? >> Say in the context of multi-user authoring env. where users can work on >> different projects simultaneously:- author1 runs a query and gets some >> result- author2 runs the same query and sees the same result- author1 >> changes some data in the result set and commits to a branch- author1 then >> runs the query in the context of his branch and sees his changed nodes- >> author2 runs the query and still sees the unchanged nodes from the base >> revision >> How do people usually manage such scenarios with Oak? Adobe's AEM 6 has >> been using Oak for a few months now, wonder how they handle such >> concurrent "projects" scenarios... >> Thx! >
