[jira] [Commented] (OAK-267) Repository fails to start with - "cannot branch off a private branch"
[
https://issues.apache.org/jira/browse/OAK-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13440422#comment-13440422
]
Stefan Guggisberg commented on OAK-267:
---
while i still can't explain how a private branch commit could possibly become a
HEAD
i've added code in svn r1376578 that throws an exception should the same error
occur again.
the callstack of that exception should hopefully help investigating the root
cause.
> Repository fails to start with - "cannot branch off a private branch"
> -
>
> Key: OAK-267
> URL: https://issues.apache.org/jira/browse/OAK-267
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mk
>Affects Versions: 0.5
>Reporter: Chetan Mehrotra
>Priority: Minor
> Attachments: stacktrace.txt
>
>
> On starting a Sling instance I am get following exception (complete
> stacktrace would be attached)
> {noformat}
> org.apache.jackrabbit.mk.api.MicroKernelException: java.lang.Exception:
> cannot branch off a private branch
> at
> org.apache.jackrabbit.mk.core.MicroKernelImpl.branch(MicroKernelImpl.java:508)
> at
> org.apache.jackrabbit.oak.kernel.KernelNodeStoreBranch.(KernelNodeStoreBranch.java:56)
> at
> org.apache.jackrabbit.oak.kernel.KernelNodeStore.branch(KernelNodeStore.java:101)
> at org.apache.jackrabbit.oak.core.RootImpl.refresh(RootImpl.java:160)
> at org.apache.jackrabbit.oak.core.RootImpl.(RootImpl.java:111)
> at
> org.apache.jackrabbit.oak.core.ContentSessionImpl.getCurrentRoot(ContentSessionImpl.java:78)
> at
> org.apache.jackrabbit.oak.jcr.SessionDelegate.(SessionDelegate.java:94)
> at
> org.apache.jackrabbit.oak.jcr.RepositoryImpl.login(RepositoryImpl.java:137)
> {noformat}
> This error does not away after restart also. On debugging
> StoredCommit#branchRootId was not null.
> I think the last shutdown was clean as per the logs. I was debugging some
> query issue which resulted in an exception so that might have something to do
> with this. Logging a bug for now to keep track. If complete repo (~70 MB of
> .mk folder)is required then let me know and I would share it somewhere
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-272) every session login causes a mk.branch operation
Stefan Guggisberg created OAK-272:
-
Summary: every session login causes a mk.branch operation
Key: OAK-272
URL: https://issues.apache.org/jira/browse/OAK-272
Project: Jackrabbit Oak
Issue Type: Bug
Components: core
Reporter: Stefan Guggisberg
here's the relevant stack trace (copied from OAK-267):
{code}
at
org.apache.jackrabbit.mk.core.MicroKernelImpl.branch(MicroKernelImpl.java:508)
at
org.apache.jackrabbit.oak.kernel.KernelNodeStoreBranch.(KernelNodeStoreBranch.java:56)
at
org.apache.jackrabbit.oak.kernel.KernelNodeStore.branch(KernelNodeStore.java:101)
at org.apache.jackrabbit.oak.core.RootImpl.refresh(RootImpl.java:160)
at org.apache.jackrabbit.oak.core.RootImpl.(RootImpl.java:111)
at
org.apache.jackrabbit.oak.core.ContentSessionImpl.getCurrentRoot(ContentSessionImpl.java:78)
at org.apache.jackrabbit.oak.jcr.SessionDelegate.(SessionDelegate.java:94)
at org.apache.jackrabbit.oak.jcr.RepositoryImpl.login(RepositoryImpl.java:137)
[...]
{code}
while investigating OAK-267 i've noticed >40k empty branch commits all based on
the same head revision.
those branch commits seem to be unnecessary since they're all empty (i.e. not
followed by write operations).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-267) Repository fails to start with - "cannot branch off a private branch"
[
https://issues.apache.org/jira/browse/OAK-267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13438780#comment-13438780
]
Stefan Guggisberg commented on OAK-267:
---
weird. looks like a corrupted repo. where can i download the .mk folder archive?
> Repository fails to start with - "cannot branch off a private branch"
> -
>
> Key: OAK-267
> URL: https://issues.apache.org/jira/browse/OAK-267
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mk
>Affects Versions: 0.5
>Reporter: Chetan Mehrotra
>Priority: Minor
> Attachments: stacktrace.txt
>
>
> On starting a Sling instance I am get following exception (complete
> stacktrace would be attached)
> {noformat}
> org.apache.jackrabbit.mk.api.MicroKernelException: java.lang.Exception:
> cannot branch off a private branch
> at
> org.apache.jackrabbit.mk.core.MicroKernelImpl.branch(MicroKernelImpl.java:508)
> at
> org.apache.jackrabbit.oak.kernel.KernelNodeStoreBranch.(KernelNodeStoreBranch.java:56)
> at
> org.apache.jackrabbit.oak.kernel.KernelNodeStore.branch(KernelNodeStore.java:101)
> at org.apache.jackrabbit.oak.core.RootImpl.refresh(RootImpl.java:160)
> at org.apache.jackrabbit.oak.core.RootImpl.(RootImpl.java:111)
> at
> org.apache.jackrabbit.oak.core.ContentSessionImpl.getCurrentRoot(ContentSessionImpl.java:78)
> at
> org.apache.jackrabbit.oak.jcr.SessionDelegate.(SessionDelegate.java:94)
> at
> org.apache.jackrabbit.oak.jcr.RepositoryImpl.login(RepositoryImpl.java:137)
> {noformat}
> This error does not away after restart also. On debugging
> StoredCommit#branchRootId was not null.
> I think the last shutdown was clean as per the logs. I was debugging some
> query issue which resulted in an exception so that might have something to do
> with this. Logging a bug for now to keep track. If complete repo (~70 MB of
> .mk folder)is required then let me know and I would share it somewhere
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-265) waitForCommit gets wrongly triggered on private branch commits
[ https://issues.apache.org/jira/browse/OAK-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved OAK-265. --- Resolution: Fixed fixed in svn r1375542 > waitForCommit gets wrongly triggered on private branch commits > -- > > Key: OAK-265 > URL: https://issues.apache.org/jira/browse/OAK-265 > Project: Jackrabbit Oak > Issue Type: Bug > Components: mk >Reporter: Stefan Guggisberg >Assignee: Stefan Guggisberg > Fix For: 0.5 > > > waitForCommit should be triggered on new (public) head revisions only, i.e. > commits on a private branch should be ignored -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-265) waitForCommit gets wrongly triggered on private branch commits
[ https://issues.apache.org/jira/browse/OAK-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated OAK-265: -- Description: waitForCommit should be triggered on new (public) head revisions only, i.e. commits on a private branch should be ignored (was: waitForCommit should on be triggered on new (public) head revisions ) > waitForCommit gets wrongly triggered on private branch commits > -- > > Key: OAK-265 > URL: https://issues.apache.org/jira/browse/OAK-265 > Project: Jackrabbit Oak > Issue Type: Bug > Components: mk >Reporter: Stefan Guggisberg >Assignee: Stefan Guggisberg > Fix For: 0.5 > > > waitForCommit should be triggered on new (public) head revisions only, i.e. > commits on a private branch should be ignored -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-265) waitForCommit gets wrongly triggered on private branch commits
[ https://issues.apache.org/jira/browse/OAK-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated OAK-265: -- Summary: waitForCommit gets wrongly triggered on private branch commits (was: waitForCommit gets triggered on private branch commits) > waitForCommit gets wrongly triggered on private branch commits > -- > > Key: OAK-265 > URL: https://issues.apache.org/jira/browse/OAK-265 > Project: Jackrabbit Oak > Issue Type: Bug > Components: mk >Reporter: Stefan Guggisberg >Assignee: Stefan Guggisberg > Fix For: 0.5 > > > waitForCommit should on be triggered on new (public) head revisions -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OAK-265) waitForCommit gets triggered on private branch commits
[ https://issues.apache.org/jira/browse/OAK-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg reassigned OAK-265: - Assignee: Stefan Guggisberg > waitForCommit gets triggered on private branch commits > -- > > Key: OAK-265 > URL: https://issues.apache.org/jira/browse/OAK-265 > Project: Jackrabbit Oak > Issue Type: Bug > Components: mk >Reporter: Stefan Guggisberg >Assignee: Stefan Guggisberg > Fix For: 0.5 > > > waitForCommit should on be triggered on new (public) head revisions -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-265) waitForCommit gets triggered on private branch commits
Stefan Guggisberg created OAK-265: - Summary: waitForCommit gets triggered on private branch commits Key: OAK-265 URL: https://issues.apache.org/jira/browse/OAK-265 Project: Jackrabbit Oak Issue Type: Bug Components: mk Reporter: Stefan Guggisberg Fix For: 0.5 waitForCommit should on be triggered on new (public) head revisions -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-264) MicroKernel.diff for depth limited, unspecified changes
[
https://issues.apache.org/jira/browse/OAK-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved OAK-264.
---
Resolution: Fixed
Fix Version/s: 0.5
good point!
fixed in svn r1375476
> MicroKernel.diff for depth limited, unspecified changes
> ---
>
> Key: OAK-264
> URL: https://issues.apache.org/jira/browse/OAK-264
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mk
>Reporter: Thomas Mueller
>Assignee: Stefan Guggisberg
>Priority: Minor
> Fix For: 0.5
>
>
> Currently the MicroKernel API specifies for the method "diff", if the depth
> parameter is used, that unspecified changes below a certain path can be
> returned as:
> ^ "/some/path"
> I would prefer the slightly more verbose:
> ^ "/some/path": {}
> Reason: It is similar to how getNode() returns node names if the depth
> limited: "some":{"path":{}}, and it makes parsing unambiguous: there is
> always a ':' after the path, whether a property was changed or a node was
> changed. Without the colon, the parser needs to look ahead to decide whether
> a node was changed or a property was changed (the token after the path could
> be the start of the next operation). And we could never ever support ':' as
> an operation because that would make parsing ambiguous.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OAK-264) MicroKernel.diff for depth limited, unspecified changes
[
https://issues.apache.org/jira/browse/OAK-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned OAK-264:
-
Assignee: Stefan Guggisberg
> MicroKernel.diff for depth limited, unspecified changes
> ---
>
> Key: OAK-264
> URL: https://issues.apache.org/jira/browse/OAK-264
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mk
>Reporter: Thomas Mueller
>Assignee: Stefan Guggisberg
>Priority: Minor
>
> Currently the MicroKernel API specifies for the method "diff", if the depth
> parameter is used, that unspecified changes below a certain path can be
> returned as:
> ^ "/some/path"
> I would prefer the slightly more verbose:
> ^ "/some/path": {}
> Reason: It is similar to how getNode() returns node names if the depth
> limited: "some":{"path":{}}, and it makes parsing unambiguous: there is
> always a ':' after the path, whether a property was changed or a node was
> changed. Without the colon, the parser needs to look ahead to decide whether
> a node was changed or a property was changed (the token after the path could
> be the start of the next operation). And we could never ever support ':' as
> an operation because that would make parsing ambiguous.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-11) Document and tighten contract of Microkernel API
[ https://issues.apache.org/jira/browse/OAK-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13438550#comment-13438550 ] Stefan Guggisberg commented on OAK-11: -- bq. getLength method is kind of vague too. It doesn't specify what should happen when blob does not exist. Does it return 0, -1, or throw MicroKernelException? good point, clarified 'getLength' and 'read' methods in svn r1375435 > Document and tighten contract of Microkernel API > > > Key: OAK-11 > URL: https://issues.apache.org/jira/browse/OAK-11 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mk >Reporter: Michael Dürig >Assignee: Julian Reschke > Labels: documentation > > We should do a review of the Microkernel API with the goal to clarify, > disambiguate and document its contract. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-11) Document and tighten contract of Microkernel API
[ https://issues.apache.org/jira/browse/OAK-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13438508#comment-13438508 ] Stefan Guggisberg commented on OAK-11: -- +1 for julian's proposal > Document and tighten contract of Microkernel API > > > Key: OAK-11 > URL: https://issues.apache.org/jira/browse/OAK-11 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mk >Reporter: Michael Dürig >Assignee: Julian Reschke > Labels: documentation > > We should do a review of the Microkernel API with the goal to clarify, > disambiguate and document its contract. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-254) waitForCommit returns null in certain situations
[ https://issues.apache.org/jira/browse/OAK-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved OAK-254. --- Resolution: Fixed fixed in svn r1374228 > waitForCommit returns null in certain situations > > > Key: OAK-254 > URL: https://issues.apache.org/jira/browse/OAK-254 > Project: Jackrabbit Oak > Issue Type: Bug > Components: mk >Reporter: Stefan Guggisberg >Assignee: Stefan Guggisberg >Priority: Minor > Fix For: 0.5 > > > waitForCommit() returns null if there were no commits since startup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-254) waitForCommit returns null in certain situations
Stefan Guggisberg created OAK-254: - Summary: waitForCommit returns null in certain situations Key: OAK-254 URL: https://issues.apache.org/jira/browse/OAK-254 Project: Jackrabbit Oak Issue Type: Bug Components: mk Reporter: Stefan Guggisberg Assignee: Stefan Guggisberg Priority: Minor Fix For: 0.5 waitForCommit() returns null if there were no commits since startup. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-239) MicroKernel.getRevisionHistory: maxEntries behavior should be documented
[ https://issues.apache.org/jira/browse/OAK-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved OAK-239. --- Resolution: Fixed Fix Version/s: 0.5 fixed in svn r1372850. > MicroKernel.getRevisionHistory: maxEntries behavior should be documented > > > Key: OAK-239 > URL: https://issues.apache.org/jira/browse/OAK-239 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mk >Reporter: Thomas Mueller >Priority: Minor > Fix For: 0.5 > > > The method MicroKernel.getRevisionHistory uses a parameter maxEntries to > limit the number of returned entries. If the implementation has to limit the > entries, it is not clear from the documentation which entries to return (the > oldest entries, the newest entries, or any x entries). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-227) MicroKernel API: add depth parameter to diff method
[
https://issues.apache.org/jira/browse/OAK-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved OAK-227.
---
Resolution: Fixed
fixed in svn r1369019
> MicroKernel API: add depth parameter to diff method
> ---
>
> Key: OAK-227
> URL: https://issues.apache.org/jira/browse/OAK-227
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mk
>Reporter: Stefan Guggisberg
>Assignee: Stefan Guggisberg
>
> a depth parameter allows to specify how deep changes should be included in
> the returned JSON diff.
> an example:
> {code}
> // initial content (/test/foo)
> String rev0 = mk.commit("/", "+\"test\":{\"foo\":{}}", null, "");
> // add /test/foo/bar
> String rev1 = mk.commit("/test/foo", "+\"bar\":{\"p1\":123}", null, "");
> // modify property /test/foo/bar/p1
> String rev2 = mk.commit("/test/foo/bar", "^\"p1\":456", null, "");
> // diff with depth -1
> String diff0 = mk.diff(rev0, rev2, "/", -1);
> // returned +"/test/foo/bar":{"p1":456}
> // diff with depth 5
> String diff1 = mk.diff(rev0, rev2, "/", 5);
> // returned +"/test/foo/bar":{"p1":456}
> // diff with depth 1
> String diff2 = mk.diff(rev0, rev2, "/", 1);
> // returned ^"/test/foo", indicating that there are changes below /test/foo
> // diff with depth 0
> String diff3 = mk.diff(rev0, rev2, "/", 0);
> // returned ^"/test", indicating that there are changes below /test
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-227) MicroKernel API: add depth parameter to diff method
[
https://issues.apache.org/jira/browse/OAK-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg updated OAK-227:
--
Description:
a depth parameter allows to specify how deep changes should be included in the
returned JSON diff.
an example:
{code}
// initial content (/test/foo)
String rev0 = mk.commit("/", "+\"test\":{\"foo\":{}}", null, "");
// add /test/foo/bar
String rev1 = mk.commit("/test/foo", "+\"bar\":{\"p1\":123}", null, "");
// modify property /test/foo/bar/p1
String rev2 = mk.commit("/test/foo/bar", "^\"p1\":456", null, "");
// diff with depth -1
String diff0 = mk.diff(rev0, rev2, "/", -1);
// returned +"/test/foo/bar":{"p1":456}
// diff with depth 5
String diff1 = mk.diff(rev0, rev2, "/", 5);
// returned +"/test/foo/bar":{"p1":456}
// diff with depth 1
String diff2 = mk.diff(rev0, rev2, "/", 1);
// returned ^"/test/foo", indicating that there are changes below /test/foo
// diff with depth 0
String diff3 = mk.diff(rev0, rev2, "/", 0);
// returned ^"/test", indicating that there are changes below /test
{code}
was:
a depth parameter allows to specify how deep changes should be included in the
returned JSON diff.
an example:
{code}
// initial content (/test/foo)
String rev0 = mk.commit("/", "+\"test\":{\"foo\":{}}", null, "");
// add /test/foo/bar
String rev1 = mk.commit("/test/foo", "+\"bar\":{\"p1\":123}", null, "");
// modify property /test/foo/bar/p1
String rev2 = mk.commit("/test/foo/bar", "^\"p1\":456", null, "");
// diff with depth 5
String diff1 = mk.diff(rev0, rev2, "/", 5);
// returned +"/test/foo/bar":{"p1":456}
// diff with depth 1
String diff1 = mk.diff(rev0, rev2, "/", 1);
// returned ^"/test", indicating that there are changes below /test
{code}
> MicroKernel API: add depth parameter to diff method
> ---
>
> Key: OAK-227
> URL: https://issues.apache.org/jira/browse/OAK-227
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mk
>Reporter: Stefan Guggisberg
>Assignee: Stefan Guggisberg
>
> a depth parameter allows to specify how deep changes should be included in
> the returned JSON diff.
> an example:
> {code}
> // initial content (/test/foo)
> String rev0 = mk.commit("/", "+\"test\":{\"foo\":{}}", null, "");
> // add /test/foo/bar
> String rev1 = mk.commit("/test/foo", "+\"bar\":{\"p1\":123}", null, "");
> // modify property /test/foo/bar/p1
> String rev2 = mk.commit("/test/foo/bar", "^\"p1\":456", null, "");
> // diff with depth -1
> String diff0 = mk.diff(rev0, rev2, "/", -1);
> // returned +"/test/foo/bar":{"p1":456}
> // diff with depth 5
> String diff1 = mk.diff(rev0, rev2, "/", 5);
> // returned +"/test/foo/bar":{"p1":456}
> // diff with depth 1
> String diff2 = mk.diff(rev0, rev2, "/", 1);
> // returned ^"/test/foo", indicating that there are changes below /test/foo
> // diff with depth 0
> String diff3 = mk.diff(rev0, rev2, "/", 0);
> // returned ^"/test", indicating that there are changes below /test
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-227) MicroKernel API: add depth parameter to diff method
[
https://issues.apache.org/jira/browse/OAK-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg updated OAK-227:
--
Summary: MicroKernel API: add depth parameter to diff method (was: add
depth parameter to MicroKernel#diff method)
> MicroKernel API: add depth parameter to diff method
> ---
>
> Key: OAK-227
> URL: https://issues.apache.org/jira/browse/OAK-227
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mk
>Reporter: Stefan Guggisberg
>Assignee: Stefan Guggisberg
>
> a depth parameter allows to specify how deep changes should be included in
> the returned JSON diff.
> an example:
> {code}
> // initial content (/test/foo)
> String rev0 = mk.commit("/", "+\"test\":{\"foo\":{}}", null, "");
> // add /test/foo/bar
> String rev1 = mk.commit("/test/foo", "+\"bar\":{\"p1\":123}", null, "");
> // modify property /test/foo/bar/p1
> String rev2 = mk.commit("/test/foo/bar", "^\"p1\":456", null, "");
> // diff with depth 5
> String diff1 = mk.diff(rev0, rev2, "/", 5);
> // returned +"/test/foo/bar":{"p1":456}
> // diff with depth 1
> String diff1 = mk.diff(rev0, rev2, "/", 1);
> // returned ^"/test", indicating that there are changes below /test
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-227) add depth parameter to MicroKernel#diff method
Stefan Guggisberg created OAK-227:
-
Summary: add depth parameter to MicroKernel#diff method
Key: OAK-227
URL: https://issues.apache.org/jira/browse/OAK-227
Project: Jackrabbit Oak
Issue Type: New Feature
Components: mk
Reporter: Stefan Guggisberg
Assignee: Stefan Guggisberg
a depth parameter allows to specify how deep changes should be included in the
returned JSON diff.
an example:
{code}
// initial content (/test/foo)
String rev0 = mk.commit("/", "+\"test\":{\"foo\":{}}", null, "");
// add /test/foo/bar
String rev1 = mk.commit("/test/foo", "+\"bar\":{\"p1\":123}", null, "");
// modify property /test/foo/bar/p1
String rev2 = mk.commit("/test/foo/bar", "^\"p1\":456", null, "");
// diff with depth 5
String diff1 = mk.diff(rev0, rev2, "/", 5);
// returned +"/test/foo/bar":{"p1":456}
// diff with depth 1
String diff1 = mk.diff(rev0, rev2, "/", 1);
// returned ^"/test", indicating that there are changes below /test
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-210) granularity of persisted data
[ https://issues.apache.org/jira/browse/OAK-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated OAK-210: -- Issue Type: Improvement (was: Bug) > granularity of persisted data > - > > Key: OAK-210 > URL: https://issues.apache.org/jira/browse/OAK-210 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mk >Reporter: Stefan Guggisberg >Assignee: Stefan Guggisberg > > the current persistence granularity is _single nodes_ (a node consists of > properties and child node information). > instead of storing/retrieving single nodes it would IMO make sense to store > subtree aggregates of specific nodes. the choice of granularity could be > based on simple filter criteria (e.g. property value). > dynamic persistence granularity would help reducing the number of records and > r/w operations on the underlying store, thus improving performance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-210) granularity of persisted data
[
https://issues.apache.org/jira/browse/OAK-210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13423864#comment-13423864
]
Stefan Guggisberg commented on OAK-210:
---
bq. Do you see this as something to be implemented (or not) by each MK
independently (i.e. something like an MK implementation detail)?
no, that's an implementation detail that doesn't affect the semantics of the
MicroKernel API.
the most notable impact will be that the current implementation won't be able
to provide {{:hash}} values for _every_ node. but that's already explicitly
allowed for, see {{Microkernel#getNodes}} java doc.
> granularity of persisted data
> -
>
> Key: OAK-210
> URL: https://issues.apache.org/jira/browse/OAK-210
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mk
>Reporter: Stefan Guggisberg
>Assignee: Stefan Guggisberg
>
> the current persistence granularity is _single nodes_ (a node consists of
> properties and child node information).
> instead of storing/retrieving single nodes it would IMO make sense to store
> subtree aggregates of specific nodes. the choice of granularity could be
> based on simple filter criteria (e.g. property value).
> dynamic persistence granularity would help reducing the number of records and
> r/w operations on the underlying store, thus improving performance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OAK-210) granularity of persisted data
[ https://issues.apache.org/jira/browse/OAK-210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg reassigned OAK-210: - Assignee: Stefan Guggisberg > granularity of persisted data > - > > Key: OAK-210 > URL: https://issues.apache.org/jira/browse/OAK-210 > Project: Jackrabbit Oak > Issue Type: Bug > Components: mk >Reporter: Stefan Guggisberg >Assignee: Stefan Guggisberg > > the current persistence granularity is _single nodes_ (a node consists of > properties and child node information). > instead of storing/retrieving single nodes it would IMO make sense to store > subtree aggregates of specific nodes. the choice of granularity could be > based on simple filter criteria (e.g. property value). > dynamic persistence granularity would help reducing the number of records and > r/w operations on the underlying store, thus improving performance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-210) granularity of persisted data
Stefan Guggisberg created OAK-210: - Summary: granularity of persisted data Key: OAK-210 URL: https://issues.apache.org/jira/browse/OAK-210 Project: Jackrabbit Oak Issue Type: Bug Components: mk Reporter: Stefan Guggisberg the current persistence granularity is _single nodes_ (a node consists of properties and child node information). instead of storing/retrieving single nodes it would IMO make sense to store subtree aggregates of specific nodes. the choice of granularity could be based on simple filter criteria (e.g. property value). dynamic persistence granularity would help reducing the number of records and r/w operations on the underlying store, thus improving performance. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-77) Consolidate Utilities
[ https://issues.apache.org/jira/browse/OAK-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated OAK-77: - Component/s: (was: mk) removing mk component, there are IMO no redundant utility classes anymore in mk worth refactoring > Consolidate Utilities > - > > Key: OAK-77 > URL: https://issues.apache.org/jira/browse/OAK-77 > Project: Jackrabbit Oak > Issue Type: Task > Components: core, jcr >Reporter: angela >Priority: Minor > > as discussed on the dev list i would like to consolidate the various > utilities. getting rid of redundancies etc -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-169) Support orderable nodes
[
https://issues.apache.org/jira/browse/OAK-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410364#comment-13410364
]
Stefan Guggisberg commented on OAK-169:
---
bq. There is currently no statement about iteration order stability in the
Microkernel API contract.
good point, fixed in svn rev. 1359679
> Support orderable nodes
> ---
>
> Key: OAK-169
> URL: https://issues.apache.org/jira/browse/OAK-169
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: jcr
>Reporter: Jukka Zitting
>
> There are JCR clients that depend on the ability to explicitly specify the
> order of child nodes. That functionality is not included in the MicroKernel
> tree model, so we need to implement it either in oak-core or oak-jcr using
> something like an extra (hidden) {{oak:childOrder}} property that records the
> specified ordering of child nodes. A multi-valued string property is probably
> good enough for this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-169) Support orderable nodes
[
https://issues.apache.org/jira/browse/OAK-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13410324#comment-13410324
]
Stefan Guggisberg commented on OAK-169:
---
FWIW: here's the relevant discussion on the oak-dev list:
http://thread.gmane.org/gmane.comp.apache.jackrabbit.devel/34124/focus=34277
> Support orderable nodes
> ---
>
> Key: OAK-169
> URL: https://issues.apache.org/jira/browse/OAK-169
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: jcr
>Reporter: Jukka Zitting
>
> There are JCR clients that depend on the ability to explicitly specify the
> order of child nodes. That functionality is not included in the MicroKernel
> tree model, so we need to implement it either in oak-core or oak-jcr using
> something like an extra (hidden) {{oak:childOrder}} property that records the
> specified ordering of child nodes. A multi-valued string property is probably
> good enough for this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-169) Support orderable nodes
[
https://issues.apache.org/jira/browse/OAK-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13407954#comment-13407954
]
Stefan Guggisberg commented on OAK-169:
---
bq. No. I don't think there are any good use cases where orderability is needed
for nodes with more than at most a few thousand children.
i agree with jukka.
> Support orderable nodes
> ---
>
> Key: OAK-169
> URL: https://issues.apache.org/jira/browse/OAK-169
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: jcr
>Reporter: Jukka Zitting
>
> There are JCR clients that depend on the ability to explicitly specify the
> order of child nodes. That functionality is not included in the MicroKernel
> tree model, so we need to implement it either in oak-core or oak-jcr using
> something like an extra (hidden) {{oak:childOrder}} property that records the
> specified ordering of child nodes. A multi-valued string property is probably
> good enough for this.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-114) MicroKernel API: specify retention policy for old revisions
[ https://issues.apache.org/jira/browse/OAK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13407948#comment-13407948 ] Stefan Guggisberg commented on OAK-114: --- i agree that large exports are an important use case which is not covered by my proposal (predefined fixed retention period). determining the 'ideal' value of the fixed retention period is problematic and depends on the use cases/applications. jukka's 'implicit lease on access' model OTOH has other shortcomings (implementation complexity, potential compromise of server stability). it seems like a single approach doesn't fit all use cases. for now i suggest we postpone the discussion until we've gathered enough information/experiences about the implications of the different approaches. it might well be that we end up leaving the retention policy undefined/implementation specific. > MicroKernel API: specify retention policy for old revisions > --- > > Key: OAK-114 > URL: https://issues.apache.org/jira/browse/OAK-114 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mk >Reporter: Stefan Guggisberg >Assignee: Stefan Guggisberg > Attachments: OAK-114.patch > > > the MicroKernel API javadoc should specify the minimal guaranteed retention > period for old revisions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-167) Caching NodeStore implementation
[ https://issues.apache.org/jira/browse/OAK-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13407038#comment-13407038 ] Stefan Guggisberg commented on OAK-167: --- bq. That's a separate issue (OAK-162 as you mentioned). As explained above, whatever we do with the transient space, we in any case need some way to represent uncommitted changes in oak-core. ok, agreed > Caching NodeStore implementation > > > Key: OAK-167 > URL: https://issues.apache.org/jira/browse/OAK-167 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: core >Reporter: Jukka Zitting > > For remote MicroKernel implementations and other cases where local caching of > content is needed it would be useful to have a NodeStore implementation that > maintains a simple in-memory or on-disk cache of frequently accessed content. > Such a NodeStore implementation could also be used to better isolate the > current caching logic behind uncommitted changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-167) Caching NodeStore implementation
[ https://issues.apache.org/jira/browse/OAK-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13407028#comment-13407028 ] Stefan Guggisberg commented on OAK-167: --- IMO we have no choice but buffer transient changes (-> 'transient space') in oak-jcr. otherwise i don't see how we could efficiently remote the JCR api. buffering the transient changes in oak-core would mean that every Node.addNode and Node.setProperty would trigger a server round-trip. that's not an option. see also OAK-162. > Caching NodeStore implementation > > > Key: OAK-167 > URL: https://issues.apache.org/jira/browse/OAK-167 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: core >Reporter: Jukka Zitting > > For remote MicroKernel implementations and other cases where local caching of > content is needed it would be useful to have a NodeStore implementation that > maintains a simple in-memory or on-disk cache of frequently accessed content. > Such a NodeStore implementation could also be used to better isolate the > current caching logic behind uncommitted changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (OAK-167) Caching NodeStore implementation
[ https://issues.apache.org/jira/browse/OAK-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406581#comment-13406581 ] Stefan Guggisberg edited comment on OAK-167 at 7/5/12 8:44 AM: --- > Such a NodeStore implementation could also be used to better isolate the > current caching logic behind uncommitted changes. wouldn't that ideally be the transient space, i.e. oak-jcr? was (Author: stefan@jira): > Such a NodeStore implementation could also be used to better isolate the current caching logic behind uncommitted changes. wouldn't that ideally the transient space, i.e. oak-jcr? > Caching NodeStore implementation > > > Key: OAK-167 > URL: https://issues.apache.org/jira/browse/OAK-167 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: core >Reporter: Jukka Zitting > > For remote MicroKernel implementations and other cases where local caching of > content is needed it would be useful to have a NodeStore implementation that > maintains a simple in-memory or on-disk cache of frequently accessed content. > Such a NodeStore implementation could also be used to better isolate the > current caching logic behind uncommitted changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-114) MicroKernel API: specify retention policy for old revisions
[ https://issues.apache.org/jira/browse/OAK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406611#comment-13406611 ] Stefan Guggisberg commented on OAK-114: --- > there is a race for example between MicroKernel.getRevisionHistory and > MicroKernel.getNodes: whatever the fixed retention time might be, when the > garbage collector runs after the first but before the second call, the latter > will fail. i can't follow this argument. with my proposal a client is minimally guaranteed to be able to read revisions no older than N minutes. > MicroKernel API: specify retention policy for old revisions > --- > > Key: OAK-114 > URL: https://issues.apache.org/jira/browse/OAK-114 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mk >Reporter: Stefan Guggisberg >Assignee: Stefan Guggisberg > Attachments: OAK-114.patch > > > the MicroKernel API javadoc should specify the minimal guaranteed retention > period for old revisions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-114) MicroKernel API: specify retention policy for old revisions
[ https://issues.apache.org/jira/browse/OAK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406609#comment-13406609 ] Stefan Guggisberg commented on OAK-114: --- > Would it be possible to change "for at least 10 minutes" to "for at least 10 > minutes since last access"? the 'extend lease model', apart from introducing complex state management requirements in the microkernel, would e.g. allow misbehaved clients to compromise the stability of the mk. a client could force the mk to keep old revisions for ever and prevent vital gc cycles. i therefore don't think that we should allow clients to (explicitly or implicitly) extend the life span of a specific revision. > MicroKernel API: specify retention policy for old revisions > --- > > Key: OAK-114 > URL: https://issues.apache.org/jira/browse/OAK-114 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mk >Reporter: Stefan Guggisberg >Assignee: Stefan Guggisberg > Attachments: OAK-114.patch > > > the MicroKernel API javadoc should specify the minimal guaranteed retention > period for old revisions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-167) Caching NodeStore implementation
[ https://issues.apache.org/jira/browse/OAK-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406581#comment-13406581 ] Stefan Guggisberg commented on OAK-167: --- > Such a NodeStore implementation could also be used to better isolate the > current caching logic behind uncommitted changes. wouldn't that ideally the transient space, i.e. oak-jcr? > Caching NodeStore implementation > > > Key: OAK-167 > URL: https://issues.apache.org/jira/browse/OAK-167 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: core >Reporter: Jukka Zitting > > For remote MicroKernel implementations and other cases where local caching of > content is needed it would be useful to have a NodeStore implementation that > maintains a simple in-memory or on-disk cache of frequently accessed content. > Such a NodeStore implementation could also be used to better isolate the > current caching logic behind uncommitted changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-114) MicroKernel API: specify retention policy for old revisions
[ https://issues.apache.org/jira/browse/OAK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated OAK-114: -- Attachment: OAK-114.patch patch with a first proposal (10-minutes guaranteed retention period for head revisions) > MicroKernel API: specify retention policy for old revisions > --- > > Key: OAK-114 > URL: https://issues.apache.org/jira/browse/OAK-114 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mk >Reporter: Stefan Guggisberg >Assignee: Stefan Guggisberg > Attachments: OAK-114.patch > > > the MicroKernel API javadoc should specify the minimal guaranteed retention > period for old revisions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-114) MicroKernel API: specify retention policy for old revisions
[ https://issues.apache.org/jira/browse/OAK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated OAK-114: -- Fix Version/s: 0.3 Assignee: Stefan Guggisberg > MicroKernel API: specify retention policy for old revisions > --- > > Key: OAK-114 > URL: https://issues.apache.org/jira/browse/OAK-114 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mk >Reporter: Stefan Guggisberg >Assignee: Stefan Guggisberg > Fix For: 0.3 > > > the MicroKernel API javadoc should specify the minimal guaranteed retention > period for old revisions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-162) Oak Layering / Remoting architecture
Stefan Guggisberg created OAK-162: - Summary: Oak Layering / Remoting architecture Key: OAK-162 URL: https://issues.apache.org/jira/browse/OAK-162 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: Stefan Guggisberg i had the impression that we started the oak project with a shared view of the layering architecture (roughly based on the jackrabbit spi abstraction/partitioning model). the jcr api already implies 2 layers (client/server): - session-related operations (transient space etc) -> javax.jcr.Session - workspace-related operations (versioning, locking, node types etc) -> javax.jcr.Workspace the jackrabbit spi represents the abstraction of the workspace-related functionality and obviously lends itself to be remoted. here's my understanding of how the oak layering model should look like: 1. jcr client (oak-jcr): exposes the jcr api and implements the session-related functionality (transient space!); delegates workspace-related operations to the spi (oak api) 2. server-side repository (oak-core): exposes the spi (oak api) and implements the workspace-related operations; delegates persistence-related operations to the mk (oak api) 3. persistence layer (oak-mk): exposes the mk api and implements persistence operations the oak api and the mk api are the obvious potential remoting points. i see the following issues with the current oak code base: - the 3 layers are not properly isolated, transient space operations e.g. reach through all 3 layers. workspace mgmt e.g. is handled on the client. if either the oak or the mk api is remoted this is serious potential performance problem. - there's a mismatch between the spi and the current oak api in terms of scope/functionality; several workspace operations (such as versioning, ns mgmt, node type mgmt) don't seem to be reflected in the oak api. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-142) MicroKernel API: returning the :hash property should be optional
[
https://issues.apache.org/jira/browse/OAK-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg updated OAK-142:
--
Component/s: mk
> MicroKernel API: returning the :hash property should be optional
>
>
> Key: OAK-142
> URL: https://issues.apache.org/jira/browse/OAK-142
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mk
>Reporter: Stefan Guggisberg
>Assignee: Stefan Guggisberg
> Fix For: 0.3
>
>
> the {{:hash}} property represents the content hash of node tree rooted at the
> property's parent node.
> the {{:hash}} property is by default not included in the json tree returned
> by the {{getNodes(..)}} method but can be enabled by explicitly specifying it
> in the {{filter}} parameter.
> returning the {{:hash}} property should be optional since it might be a too
> heavy requirement on some MicroKernel implementations. an implementation
> might e.g. choose to include the {{:hash}} property only on certain nodes or
> it might choose to not support it at all.
> if however a {{:hash}} property is returned it has to obey the content hash
> contract, i.e. identical node trees must have identical {{:hash}} values and
> non-identical node trees must have different {{:hash}} values.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-142) MicroKernel API: returning the :hash property should be optional
[
https://issues.apache.org/jira/browse/OAK-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved OAK-142.
---
Resolution: Fixed
Fix Version/s: 0.3
Assignee: Stefan Guggisberg
fixed in svn r1350649
> MicroKernel API: returning the :hash property should be optional
>
>
> Key: OAK-142
> URL: https://issues.apache.org/jira/browse/OAK-142
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mk
>Reporter: Stefan Guggisberg
>Assignee: Stefan Guggisberg
> Fix For: 0.3
>
>
> the {{:hash}} property represents the content hash of node tree rooted at the
> property's parent node.
> the {{:hash}} property is by default not included in the json tree returned
> by the {{getNodes(..)}} method but can be enabled by explicitly specifying it
> in the {{filter}} parameter.
> returning the {{:hash}} property should be optional since it might be a too
> heavy requirement on some MicroKernel implementations. an implementation
> might e.g. choose to include the {{:hash}} property only on certain nodes or
> it might choose to not support it at all.
> if however a {{:hash}} property is returned it has to obey the content hash
> contract, i.e. identical node trees must have identical {{:hash}} values and
> non-identical node trees must have different {{:hash}} values.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-142) MicroKernel API: returning the :hash property should be optional
[
https://issues.apache.org/jira/browse/OAK-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg updated OAK-142:
--
Summary: MicroKernel API: returning the :hash property should be optional
(was: MicroKernel API: returning the :hash should be optional)
> MicroKernel API: returning the :hash property should be optional
>
>
> Key: OAK-142
> URL: https://issues.apache.org/jira/browse/OAK-142
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Stefan Guggisberg
>
> the {{:hash}} property represents the content hash of node tree rooted at the
> property's parent node.
> the {{:hash}} property is by default not included in the json tree returned
> by the {{getNodes(..)}} method but can be enabled by explicitly specifying it
> in the {{filter}} parameter.
> returning the {{:hash}} property should be optional since it might be a too
> heavy requirement on some MicroKernel implementations. an implementation
> might e.g. choose to include the {{:hash}} property only on certain nodes or
> it might choose to not support it at all.
> if however a {{:hash}} property is returned it has to obey the content hash
> contract, i.e. identical node trees must have identical {{:hash}} values and
> non-identical node trees must have different {{:hash}} values.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-142) MicroKernel API: returning the :hash should be optional
Stefan Guggisberg created OAK-142:
-
Summary: MicroKernel API: returning the :hash should be optional
Key: OAK-142
URL: https://issues.apache.org/jira/browse/OAK-142
Project: Jackrabbit Oak
Issue Type: Improvement
Reporter: Stefan Guggisberg
the {{:hash}} property represents the content hash of node tree rooted at the
property's parent node.
the {{:hash}} property is by default not included in the json tree returned by
the {{getNodes(..)}} method but can be enabled by explicitly specifying it in
the {{filter}} parameter.
returning the {{:hash}} property should be optional since it might be a too
heavy requirement on some MicroKernel implementations. an implementation might
e.g. choose to include the {{:hash}} property only on certain nodes or it might
choose to not support it at all.
if however a {{:hash}} property is returned it has to obey the content hash
contract, i.e. identical node trees must have identical {{:hash}} values and
non-identical node trees must have different {{:hash}} values.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-130) Unexpected result of MicroKernel#getJournal after MicroKernel#merge
[
https://issues.apache.org/jira/browse/OAK-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved OAK-130.
---
Resolution: Fixed
Fix Version/s: 0.3
fixed in svn r1350198
> Unexpected result of MicroKernel#getJournal after MicroKernel#merge
> ---
>
> Key: OAK-130
> URL: https://issues.apache.org/jira/browse/OAK-130
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mk
>Reporter: Thomas Mueller
>Assignee: Stefan Guggisberg
>Priority: Minor
> Fix For: 0.3
>
>
> There is an unexpected behavior for the following test case:
> String branch = mk.branch(head);
> branch = mk.commit("/", "+\"branch\": {}", branch, "");
> head = mk.commit("/", "+\"head\": {}", head, "");
> head = mk.merge(branch, "");
> String n = mk.getNodes("/", head, 10, 0, 10, "");
> String j = mk.getJournal(first, head, "/");
> getNodes returns both nodes ("branch" and "head"), but
> getJournal returns +"/head":{}, >"/head":"/branch"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-130) Unexpected result of MicroKernel#getJournal after MicroKernel#merge
[
https://issues.apache.org/jira/browse/OAK-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg updated OAK-130:
--
Summary: Unexpected result of MicroKernel#getJournal after
MicroKernel#merge (was: Unexpected behavior of MicroKernelImpl.merge)
> Unexpected result of MicroKernel#getJournal after MicroKernel#merge
> ---
>
> Key: OAK-130
> URL: https://issues.apache.org/jira/browse/OAK-130
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mk
>Reporter: Thomas Mueller
>Assignee: Stefan Guggisberg
>Priority: Minor
>
> There is an unexpected behavior for the following test case:
> String branch = mk.branch(head);
> branch = mk.commit("/", "+\"branch\": {}", branch, "");
> head = mk.commit("/", "+\"head\": {}", head, "");
> head = mk.merge(branch, "");
> String n = mk.getNodes("/", head, 10, 0, 10, "");
> String j = mk.getJournal(first, head, "/");
> getNodes returns both nodes ("branch" and "head"), but
> getJournal returns +"/head":{}, >"/head":"/branch"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-138) Move client/server package in oak-mk to separate project
[ https://issues.apache.org/jira/browse/OAK-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294307#comment-13294307 ] Stefan Guggisberg commented on OAK-138: --- > It also contains the MicroKernel API itself. As long as we don't want to > split the API to a separate component, things like remoting IMHO fit best > within that same component. my understanding was that we'll need to split the API to a separate component anyway sooner or later. with the current setup alternative mk implementations require an explicit dependency on the 'default' implementation in oak-mk, including all transitive dependencies such as h2 etc. i find that weird. IMHO an alternative mk implementation should only require a dependency on the MicroKernel API. therefore, +1 for oak-mk-remote +1 for oak-mk-api > Move client/server package in oak-mk to separate project > > > Key: OAK-138 > URL: https://issues.apache.org/jira/browse/OAK-138 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, it, mk, run >Affects Versions: 0.3 >Reporter: Dominique Pfister >Assignee: Dominique Pfister > > As a further cleanup step in OAK-13, I'd like to move the packages > o.a.j.mk.client and o.a.j.mk.server and referenced classes in oak-mk to a > separate project, e.g. oak-mk-remote. > This new project will then be added as a dependency to: > oak-core > oak-run > oak-it-mk -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-138) Move client/server package in oak-mk to separate project
[ https://issues.apache.org/jira/browse/OAK-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293483#comment-13293483 ] Stefan Guggisberg commented on OAK-138: --- +1 > Move client/server package in oak-mk to separate project > > > Key: OAK-138 > URL: https://issues.apache.org/jira/browse/OAK-138 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, it, mk, run >Affects Versions: 0.3 >Reporter: Dominique Pfister >Assignee: Dominique Pfister > > As a further cleanup step in OAK-13, I'd like to move the packages > o.a.j.mk.client and o.a.j.mk.server and referenced classes in oak-mk to a > separate project, e.g. oak-mk-remote. > This new project will then be added as a dependency to: > oak-core > oak-run > oak-it-mk -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (OAK-13) Cleanup org.apache.jackrabbit.mk
[
https://issues.apache.org/jira/browse/OAK-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291032#comment-13291032
]
Stefan Guggisberg edited comment on OAK-13 at 6/7/12 2:31 PM:
--
> To finalise this I propose to:
>
> * move {{o.a.j.mk.index}} to {{o.a.j.oak.query.index}}
> * move everything which is required for the query implementation in oak core
> from {{o.a.j.mk.simpl}} to {{o.a.j.oak.query}} or an adequate sub-package
> thereof.
> * move {{o.a.j.mk.wrapper}} to a utility package in oak-mk since this package
> essentially contains Microkernel implementations.
the problem is that some classes in the o.a.j.mk.wrapper package have
dependencies on o.a.j.mk.simple code.
if they would only depend on the MicroKernel api i'd suggest to move them to
new module (e.g. oak-mk-commons).
> * move the classes in {{o.a.j.mk.util}} to util packages in oak-mk, oak-core
> or oak-commons as required.
> * move {{o.a.j.mk.MicroKernelFactory}} to oak-mk since this class is concernd
> with Microkernel implementations only.
-1, we should try to resolve the MicroKernelFactory issue instead of moving it
around. see [1] for a related discussion.
> * move the Simple implementation in {{o.a.j.mk.simple}} either to an package
> {{experimental}} in oak-mk, to an own sub-module oak-experimental or to the
> sandbox.
-1 for moving it to oak-mk. we had that situation (different implementations in
the same module) before. i'd like to avoid that because it's IMO confusing.
[1] http://oak.markmail.org/thread/j34cd5m6ti5nwuit
was (Author: stefan@jira):
> To finalise this I propose to:
>
> * move {{o.a.j.mk.index}} to {{o.a.j.oak.query.index}}
> * move everything which is required for the query implementation in oak core
> from {{o.a.j.mk.simpl}} to {{o.a.j.oak.query}} or an adequate sub-package
> thereof.
> * move {{o.a.j.mk.wrapper}} to a utility package in oak-mk since this package
> essentially contains Microkernel implementations.
the problem is that some classes in the o.a.j.mk.wrapper package have
dependencies on o.a.j.mk.simple code.
if they would only depend on the MicroKernel api i'd suggest to move them to
new module (e.g. oak-mk-commons).
> * move the classes in {{o.a.j.mk.util}} to util packages in oak-mk, oak-core
> or oak-commons as required.
> * move {{o.a.j.mk.MicroKernelFactory}} to oak-mk since this class is concernd
> with Microkernel implementations only.
-1, we should try to resolve the MicroKernelFactory issue instead of moving it
around. see [1] for a related discussion.
> * move the Simple implementation in {{o.a.j.mk.simple}} either to an package
> {{experimental}} in oak-mk, to an own sub-module oak-experimental or to the
> sandbox.
-1 for moving it to oak-mk. we had that situation (different implementations in
the same module) before. i'd like to avoid that because it's IMO confusing.
> Cleanup org.apache.jackrabbit.mk
>
>
> Key: OAK-13
> URL: https://issues.apache.org/jira/browse/OAK-13
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core
>Reporter: angela
>
> imo we should clean up the org.apache.jackrabbit.mk.* packages that are
> currently
> located in the oak-core module.
> for me it is really hard to destinguish between code that is really part of
> the
> productive code base for the oak project and code that is purely experimental
> chunk and leftover.
> in order to become familiar with the code that would be helpful for me and
> anybody else that will contribute to the project.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-13) Cleanup org.apache.jackrabbit.mk
[
https://issues.apache.org/jira/browse/OAK-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291032#comment-13291032
]
Stefan Guggisberg commented on OAK-13:
--
> To finalise this I propose to:
>
> * move {{o.a.j.mk.index}} to {{o.a.j.oak.query.index}}
> * move everything which is required for the query implementation in oak core
> from {{o.a.j.mk.simpl}} to {{o.a.j.oak.query}} or an adequate sub-package
> thereof.
> * move {{o.a.j.mk.wrapper}} to a utility package in oak-mk since this package
> essentially contains Microkernel implementations.
the problem is that some classes in the o.a.j.mk.wrapper package have
dependencies on o.a.j.mk.simple code.
if they would only depend on the MicroKernel api i'd suggest to move them to
new module (e.g. oak-mk-commons).
> * move the classes in {{o.a.j.mk.util}} to util packages in oak-mk, oak-core
> or oak-commons as required.
> * move {{o.a.j.mk.MicroKernelFactory}} to oak-mk since this class is concernd
> with Microkernel implementations only.
-1, we should try to resolve the MicroKernelFactory issue instead of moving it
around. see [1] for a related discussion.
> * move the Simple implementation in {{o.a.j.mk.simple}} either to an package
> {{experimental}} in oak-mk, to an own sub-module oak-experimental or to the
> sandbox.
-1 for moving it to oak-mk. we had that situation (different implementations in
the same module) before. i'd like to avoid that because it's IMO confusing.
> Cleanup org.apache.jackrabbit.mk
>
>
> Key: OAK-13
> URL: https://issues.apache.org/jira/browse/OAK-13
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core
>Reporter: angela
>
> imo we should clean up the org.apache.jackrabbit.mk.* packages that are
> currently
> located in the oak-core module.
> for me it is really hard to destinguish between code that is really part of
> the
> productive code base for the oak project and code that is purely experimental
> chunk and leftover.
> in order to become familiar with the code that would be helpful for me and
> anybody else that will contribute to the project.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OAK-130) Unexpected behavior of MicroKernelImpl.merge
[
https://issues.apache.org/jira/browse/OAK-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned OAK-130:
-
Assignee: Stefan Guggisberg
> Unexpected behavior of MicroKernelImpl.merge
>
>
> Key: OAK-130
> URL: https://issues.apache.org/jira/browse/OAK-130
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mk
>Reporter: Thomas Mueller
>Assignee: Stefan Guggisberg
>Priority: Minor
>
> There is an unexpected behavior for the following test case:
> String branch = mk.branch(head);
> branch = mk.commit("/", "+\"branch\": {}", branch, "");
> head = mk.commit("/", "+\"head\": {}", head, "");
> head = mk.merge(branch, "");
> String n = mk.getNodes("/", head, 10, 0, 10, "");
> String j = mk.getJournal(first, head, "/");
> getNodes returns both nodes ("branch" and "head"), but
> getJournal returns +"/head":{}, >"/head":"/branch"
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-13) Cleanup org.apache.jackrabbit.mk
[ https://issues.apache.org/jira/browse/OAK-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated OAK-13: - Component/s: (was: mk) core > Cleanup org.apache.jackrabbit.mk > > > Key: OAK-13 > URL: https://issues.apache.org/jira/browse/OAK-13 > Project: Jackrabbit Oak > Issue Type: Task > Components: core >Reporter: angela > > imo we should clean up the org.apache.jackrabbit.mk.* packages that are > currently > located in the oak-core module. > for me it is really hard to destinguish between code that is really part of > the > productive code base for the oak project and code that is purely experimental > chunk and leftover. > in order to become familiar with the code that would be helpful for me and > anybody else that will contribute to the project. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-126) remove unused code
[ https://issues.apache.org/jira/browse/OAK-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved OAK-126. --- Resolution: Fixed Fix Version/s: 0.3 Assignee: Stefan Guggisberg done in svn r1345209 > remove unused code > -- > > Key: OAK-126 > URL: https://issues.apache.org/jira/browse/OAK-126 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mk >Reporter: Stefan Guggisberg >Assignee: Stefan Guggisberg >Priority: Minor > Fix For: 0.3 > > > in oak-mk there are a couple of classes that are (currently) not used. > e.g. > o.a.jackrabbit.mk.persistence.BDbPersistence > o.a.jackrabbit.mk.persistence.FSPersistence > o.a.jackrabbit.mk.persistence.MongoPersistence > o.a.jackrabbit.mk.fs.* > o.a.jackrabbit.mk.blobs.MongoBlobStore > in the interest of a leaner code base > and clearer structure i'd like to > remove such unused code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-56) File system abstraction
[ https://issues.apache.org/jira/browse/OAK-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved OAK-56. -- Resolution: Won't Fix resolving as "won't fix" for now, as discussed with thomas off-list. we will revisit this topic once we have a concrete use case/need for a file system abstraction in oak-mk. > File system abstraction > --- > > Key: OAK-56 > URL: https://issues.apache.org/jira/browse/OAK-56 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mk >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Minor > > A file system abstraction allows to add new features (cross cutting concerns) > in a modular way, for example: > - detection and special behavior of out-of-disk space situation > - profiling and statistics over JMX > - re-try on file system problems > - encryption > - file system monitoring > - replication / real-time backup on the file system level (for clustering) > - caching (improved performance for CRX) > - allows to easily switch to faster file system APIs (FileChannel, memory > mapped files) > - debugging (for example, logging all file system operations) > - allows to implement s3 / hadoop / mongodb / ... file systems - not only by > us but from 3th party, possibly the end user > - zip file system (for example to support read-only, compressed repositories) > - testing: simulating out of disk space and out of memory (ensure the > repository doesn't corrupt in this case) > - testing: simulate very large files (using an in-memory file system) > - splitting very large files in 2 gb blocks (FAT and other file systems that > don't support large files) > - data compression (if needed) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-126) remove unused code
Stefan Guggisberg created OAK-126: - Summary: remove unused code Key: OAK-126 URL: https://issues.apache.org/jira/browse/OAK-126 Project: Jackrabbit Oak Issue Type: Improvement Components: mk Reporter: Stefan Guggisberg Priority: Minor in oak-mk there are a couple of classes that are (currently) not used. e.g. o.a.jackrabbit.mk.persistence.BDbPersistence o.a.jackrabbit.mk.persistence.FSPersistence o.a.jackrabbit.mk.persistence.MongoPersistence o.a.jackrabbit.mk.fs.* o.a.jackrabbit.mk.blobs.MongoBlobStore in the interest of a leaner code base and clearer structure i'd like to remove such unused code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (OAK-32) Drop MicroKernel.dispose()
[ https://issues.apache.org/jira/browse/OAK-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13287381#comment-13287381 ] Stefan Guggisberg edited comment on OAK-32 at 6/1/12 2:09 PM: -- fixed as proposed in svn r1345141 the MicroKernelFactory issue (i.e. how should MicroKernel instances ideally be created) has not been addressed. was (Author: stefan@jira): fixed as proposed in svn r1345141 the MicroKernelFactory issue (who should MicroKernel instances ideally be created) has not been addressed. > Drop MicroKernel.dispose() > -- > > Key: OAK-32 > URL: https://issues.apache.org/jira/browse/OAK-32 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mk >Reporter: Jukka Zitting >Assignee: Stefan Guggisberg > Fix For: 0.3 > > Attachments: OAK-32.patch > > > Just like a client of the MicroKernel interface doesn't know how a MK > instance is created, there should not be a need for a client to be able to > dispose an instance. For example the lifecycle of a MK instance running as an > OSGi service (or any other component framework) is managed by the framework, > not by clients. Thus I suggest that the MicroKernel.dispose() method is > removed. > The only piece of code that's notably affected by this change is the > MicroKernelFactory class still in oak-core and any client code that uses it > to construct new MicroKernel instances. I think we should replace the MKF > class with a more generic solution as outlined in OAK-17. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (OAK-32) Drop MicroKernel.dispose()
[ https://issues.apache.org/jira/browse/OAK-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13287381#comment-13287381 ] Stefan Guggisberg edited comment on OAK-32 at 6/1/12 1:14 PM: -- fixed as proposed in svn r1345141 the MicroKernelFactory issue (who should MicroKernel instances ideally be created) has not been addressed. was (Author: stefan@jira): fixed as proposed in svn r1345141 the MicroKernelFactory issue (who should MicroKernel instances ideally be created) has not been adressed. > Drop MicroKernel.dispose() > -- > > Key: OAK-32 > URL: https://issues.apache.org/jira/browse/OAK-32 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mk >Reporter: Jukka Zitting >Assignee: Stefan Guggisberg > Fix For: 0.3 > > Attachments: OAK-32.patch > > > Just like a client of the MicroKernel interface doesn't know how a MK > instance is created, there should not be a need for a client to be able to > dispose an instance. For example the lifecycle of a MK instance running as an > OSGi service (or any other component framework) is managed by the framework, > not by clients. Thus I suggest that the MicroKernel.dispose() method is > removed. > The only piece of code that's notably affected by this change is the > MicroKernelFactory class still in oak-core and any client code that uses it > to construct new MicroKernel instances. I think we should replace the MKF > class with a more generic solution as outlined in OAK-17. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-32) Drop MicroKernel.dispose()
[ https://issues.apache.org/jira/browse/OAK-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved OAK-32. -- Resolution: Fixed Fix Version/s: 0.3 Assignee: Stefan Guggisberg fixed as proposed in svn r1345141 the MicroKernelFactory issue (who should MicroKernel instances ideally be created) has not been adressed. > Drop MicroKernel.dispose() > -- > > Key: OAK-32 > URL: https://issues.apache.org/jira/browse/OAK-32 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mk >Reporter: Jukka Zitting >Assignee: Stefan Guggisberg > Fix For: 0.3 > > Attachments: OAK-32.patch > > > Just like a client of the MicroKernel interface doesn't know how a MK > instance is created, there should not be a need for a client to be able to > dispose an instance. For example the lifecycle of a MK instance running as an > OSGi service (or any other component framework) is managed by the framework, > not by clients. Thus I suggest that the MicroKernel.dispose() method is > removed. > The only piece of code that's notably affected by this change is the > MicroKernelFactory class still in oak-core and any client code that uses it > to construct new MicroKernel instances. I think we should replace the MKF > class with a more generic solution as outlined in OAK-17. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-117) MicroKernel API: add delete(String blobId) method
[ https://issues.apache.org/jira/browse/OAK-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved OAK-117. --- Resolution: Won't Fix ok, you've convinced me. i forgot that the binary data is content-addressed. resolving my half-cocked proposal as "won't fix" > MicroKernel API: add delete(String blobId) method > - > > Key: OAK-117 > URL: https://issues.apache.org/jira/browse/OAK-117 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Stefan Guggisberg >Assignee: Stefan Guggisberg > > the MicroKernel API does provide methods for writing and reading binary data; > but there's no method to delete binary data. > i suggest we add the following method: > boolean delete(String blobId) throws MicroKernelException; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OAK-117) MicroKernel API: add delete(String blobId) method
[ https://issues.apache.org/jira/browse/OAK-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg reassigned OAK-117: - Assignee: Stefan Guggisberg > MicroKernel API: add delete(String blobId) method > - > > Key: OAK-117 > URL: https://issues.apache.org/jira/browse/OAK-117 > Project: Jackrabbit Oak > Issue Type: Improvement >Reporter: Stefan Guggisberg >Assignee: Stefan Guggisberg > > the MicroKernel API does provide methods for writing and reading binary data; > but there's no method to delete binary data. > i suggest we add the following method: > boolean delete(String blobId) throws MicroKernelException; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-117) MicroKernel API: add delete(String blobId) method
Stefan Guggisberg created OAK-117: - Summary: MicroKernel API: add delete(String blobId) method Key: OAK-117 URL: https://issues.apache.org/jira/browse/OAK-117 Project: Jackrabbit Oak Issue Type: Improvement Reporter: Stefan Guggisberg the MicroKernel API does provide methods for writing and reading binary data; but there's no method to delete binary data. i suggest we add the following method: boolean delete(String blobId) throws MicroKernelException; -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-32) Drop MicroKernel.dispose()
[ https://issues.apache.org/jira/browse/OAK-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated OAK-32: - Attachment: OAK-32.patch proposed patch > Drop MicroKernel.dispose() > -- > > Key: OAK-32 > URL: https://issues.apache.org/jira/browse/OAK-32 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mk >Reporter: Jukka Zitting > Attachments: OAK-32.patch > > > Just like a client of the MicroKernel interface doesn't know how a MK > instance is created, there should not be a need for a client to be able to > dispose an instance. For example the lifecycle of a MK instance running as an > OSGi service (or any other component framework) is managed by the framework, > not by clients. Thus I suggest that the MicroKernel.dispose() method is > removed. > The only piece of code that's notably affected by this change is the > MicroKernelFactory class still in oak-core and any client code that uses it > to construct new MicroKernel instances. I think we should replace the MKF > class with a more generic solution as outlined in OAK-17. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-116) MicroKernel API: clarify semantics of getNodes depth, offset and count parameters
Stefan Guggisberg created OAK-116:
-
Summary: MicroKernel API: clarify semantics of getNodes depth,
offset and count parameters
Key: OAK-116
URL: https://issues.apache.org/jira/browse/OAK-116
Project: Jackrabbit Oak
Issue Type: Improvement
Components: mk
Reporter: Stefan Guggisberg
Fix For: 0.3
{{MicroKernel.getNode(String path, String revisionId, int depth, long offset,
int count, String filter)}}
the semantics of {{depth}} as currently documented in the javadoc is
inconsistent:
- depth=0 returns empty child node objects
- depth=1 OTOH doesn't return empty grand children objects
the amount of information returned on the deepest level should IMO be
independent of the depth value.
{{count}} as currently documented is only applied to the root of the returned
subtree. this would imply that the implementation has to always return *all*
child nodes on deeper levels, even for potentially very large child node sets.
i suggest we rename {{count}} to {{maxChildNodes}} and apply it on every level
of the returned subtree.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OAK-116) MicroKernel API: clarify semantics of getNodes depth, offset and count parameters
[
https://issues.apache.org/jira/browse/OAK-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned OAK-116:
-
Assignee: Stefan Guggisberg
> MicroKernel API: clarify semantics of getNodes depth, offset and count
> parameters
> -
>
> Key: OAK-116
> URL: https://issues.apache.org/jira/browse/OAK-116
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mk
>Reporter: Stefan Guggisberg
>Assignee: Stefan Guggisberg
> Fix For: 0.3
>
>
> {{MicroKernel.getNode(String path, String revisionId, int depth, long offset,
> int count, String filter)}}
> the semantics of {{depth}} as currently documented in the javadoc is
> inconsistent:
> - depth=0 returns empty child node objects
> - depth=1 OTOH doesn't return empty grand children objects
> the amount of information returned on the deepest level should IMO be
> independent of the depth value.
> {{count}} as currently documented is only applied to the root of the returned
> subtree. this would imply that the implementation has to always return *all*
> child nodes on deeper levels, even for potentially very large child node sets.
> i suggest we rename {{count}} to {{maxChildNodes}} and apply it on every
> level of the returned subtree.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-114) MicroKernel API: specify retention policy for old revisions
Stefan Guggisberg created OAK-114: - Summary: MicroKernel API: specify retention policy for old revisions Key: OAK-114 URL: https://issues.apache.org/jira/browse/OAK-114 Project: Jackrabbit Oak Issue Type: Improvement Components: mk Reporter: Stefan Guggisberg the MicroKernel API javadoc should specify the minimal guaranteed retention period for old revisions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-113) drop MicroKernel getNodes(String, String) convenience signature
Stefan Guggisberg created OAK-113:
-
Summary: drop MicroKernel getNodes(String, String) convenience
signature
Key: OAK-113
URL: https://issues.apache.org/jira/browse/OAK-113
Project: Jackrabbit Oak
Issue Type: Improvement
Components: mk
Reporter: Stefan Guggisberg
Assignee: Stefan Guggisberg
Priority: Minor
Fix For: 0.3
the MK API provides two getNodes signatures:
- {{getNodes(String, String)}}
- {{getNodes(String, String, int, long, int, String)}}
the former is a convenience method and equivalent to
{{getNodes(path, revisionId, 1, 0, -1, null)}}.
it's currently only used in test cases. in order to
streamline the API and the javadoc i suggest to drop it.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-37) Use nullability annotation to enforce/document API contract
[ https://issues.apache.org/jira/browse/OAK-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated OAK-37: - Component/s: (was: mk) > Use nullability annotation to enforce/document API contract > --- > > Key: OAK-37 > URL: https://issues.apache.org/jira/browse/OAK-37 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, jcr >Reporter: Michael Dürig >Assignee: Julian Reschke > Attachments: nullability.patch, nullability.patch > > > In a discussion about exception handling on the dev list [1] Julian brough up > the idea of using nullability annotations in APIs. I think we should decide > on which one to use and start using them whereever apropriate. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-107) testConcurrentMergeGC fails intermittently
[ https://issues.apache.org/jira/browse/OAK-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated OAK-107: -- Component/s: mk > testConcurrentMergeGC fails intermittently > -- > > Key: OAK-107 > URL: https://issues.apache.org/jira/browse/OAK-107 > Project: Jackrabbit Oak > Issue Type: Bug > Components: mk >Affects Versions: 0.2.1 >Reporter: Dominique Pfister > Attachments: stacktrace.txt > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-32) Drop MicroKernel.dispose()
[ https://issues.apache.org/jira/browse/OAK-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated OAK-32: - Component/s: mk > Drop MicroKernel.dispose() > -- > > Key: OAK-32 > URL: https://issues.apache.org/jira/browse/OAK-32 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mk >Reporter: Jukka Zitting > > Just like a client of the MicroKernel interface doesn't know how a MK > instance is created, there should not be a need for a client to be able to > dispose an instance. For example the lifecycle of a MK instance running as an > OSGi service (or any other component framework) is managed by the framework, > not by clients. Thus I suggest that the MicroKernel.dispose() method is > removed. > The only piece of code that's notably affected by this change is the > MicroKernelFactory class still in oak-core and any client code that uses it > to construct new MicroKernel instances. I think we should replace the MKF > class with a more generic solution as outlined in OAK-17. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-12) Implement a test suite for the MicroKernel
[ https://issues.apache.org/jira/browse/OAK-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved OAK-12. -- Resolution: Fixed Fix Version/s: 0.3 MicroKernelIT covers all MicroKernel API methods. resolving as fixed > Implement a test suite for the MicroKernel > -- > > Key: OAK-12 > URL: https://issues.apache.org/jira/browse/OAK-12 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: mk >Reporter: Michael Dürig >Assignee: Stefan Guggisberg > Labels: test > Fix For: 0.3 > > > We should have a test suite which thourougly covers the contract of the > MicroKernel API -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OAK-75) specify format and semantics of 'filter' parameter in MicroKernel API
[
https://issues.apache.org/jira/browse/OAK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned OAK-75:
Assignee: Stefan Guggisberg
> specify format and semantics of 'filter' parameter in MicroKernel API
> -
>
> Key: OAK-75
> URL: https://issues.apache.org/jira/browse/OAK-75
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mk
>Reporter: Stefan Guggisberg
>Assignee: Stefan Guggisberg
> Attachments: OAK-83.patch
>
>
> the following MicroKernel methods contain a 'filter' string parameter:
> - getJournal
> - diff
> - getNodes
> through the filter an API client could e.g. specify:
> - special 'meta' properties to be included (e.g. ":hash")
> - glob patterns on the names of properties/child nodes to be included/excluded
> - path filter (for getJournal and diff)
> format/detailed semantics TBD, here's an initial proposal (json):
> {code}
> {
> "path" : "/some/path",
> "incl" : [ ":hash", "*" ],
> "excl" : [ "tmp*" ]
> }
> {code}
> name filter patterns should ideally be the same
> format as specified for JCR Node.getNodes/getProperties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-45) Add support for branching and merging of private copies to MicroKernel
[
https://issues.apache.org/jira/browse/OAK-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved OAK-45.
--
Resolution: Fixed
Fix Version/s: 0.3
there's javadoc, a basic integration test in MicroKernelIT
and an implementation in oak-mk; resolving as fixed
> Add support for branching and merging of private copies to MicroKernel
> --
>
> Key: OAK-45
> URL: https://issues.apache.org/jira/browse/OAK-45
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mk
>Reporter: Michael Dürig
>Assignee: Stefan Guggisberg
> Fix For: 0.3
>
> Attachments: OAK-45__OOME.patch
>
>
> As discussed on the dev list [1] we should add support to the Microkernel for
> branching of a private working copy which can be merged back later:
> {code}
> String addLotsOfData(MicroKernel mk) {
> String baseRevision = mk.getHeadRevision();
> String branchRevision = mk.branch(baseRevision);
> for (int i = 0; i < 100; i++) {
> branchRevision = mk.commit("/", "+\"node" + i + "\":{}",
> branchRevision, null);
> }
> return mk.merge(branchRevision, baseRevision); }
> {code}
> [1] http://markmail.org/message/jbbut6vzvmmjqonr
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OAK-45) Add support for branching and merging of private copies to MicroKernel
[
https://issues.apache.org/jira/browse/OAK-45?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned OAK-45:
Assignee: Stefan Guggisberg
> Add support for branching and merging of private copies to MicroKernel
> --
>
> Key: OAK-45
> URL: https://issues.apache.org/jira/browse/OAK-45
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mk
>Reporter: Michael Dürig
>Assignee: Stefan Guggisberg
> Attachments: OAK-45__OOME.patch
>
>
> As discussed on the dev list [1] we should add support to the Microkernel for
> branching of a private working copy which can be merged back later:
> {code}
> String addLotsOfData(MicroKernel mk) {
> String baseRevision = mk.getHeadRevision();
> String branchRevision = mk.branch(baseRevision);
> for (int i = 0; i < 100; i++) {
> branchRevision = mk.commit("/", "+\"node" + i + "\":{}",
> branchRevision, null);
> }
> return mk.merge(branchRevision, baseRevision); }
> {code}
> [1] http://markmail.org/message/jbbut6vzvmmjqonr
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (OAK-75) specify format and semantics of 'filter' parameter in MicroKernel API
[
https://issues.apache.org/jira/browse/OAK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13281630#comment-13281630
]
Stefan Guggisberg edited comment on OAK-75 at 5/23/12 2:43 PM:
---
{noformat}
added initial support for glob-based getNodes filter
in svn r1341873.
the format is as suggested by michael. however, since \ (backslash)
needs to be escaped in json (leading to pretty awkward java strings
such as e.g. "{nodes:[\"foo*\"]}"}) i've chosen to require the
literal * to be escaped instead of the wildcard.
Glob Syntax:
a nodes or properties filter consists of one or more globs.
a glob prefixed by - (dash) is treated as an exclusion pattern;
all others are considered inclusion patterns.
a leading - (dash) must be escaped by prepending \ (backslash)
if it should be interpreted as a literal.
* (asterisk) serves as a wildcard, i.e. it matches any substring
in the target name.
* (asterisk) occurrences within the glob to be interpreted as literals
must be escaped by prepending \ (backslash).
a filter matches a target name if any of the inclusion patterns match
but none of the exclusion patterns.
{noformat}
was (Author: stefan@jira):
{noformat}
added initial support for glob-based getNodes filter in svn r1341873.
the format is as suggested by michael. however, since \ (backslash) needs to be
escaped in json (leading to pretty awkward java strings such as e.g.
"{nodes:[\"foo*\"]}"}) i've chosen to require the literal * to be escaped
instead of the wildcard.
Glob Syntax:
a nodes or properties filter consists of one or more globs.
a glob prefixed by - (dash) is treated as an exclusion pattern; all others are
considered inclusion patterns.
a leading - (dash) must be escaped by prepending \ (backslash) if it should be
interpreted as a literal.
* (asterisk) serves as a wildcard, i.e. it matches any substring in the target
name.
* (asterisk) occurrences within the glob to be interpreted as literals must be
escaped by prepending \ (backslash).
a filter matches a target name if any of the inclusion patterns match but none
of the exclusion patterns.
{noformat}
> specify format and semantics of 'filter' parameter in MicroKernel API
> -
>
> Key: OAK-75
> URL: https://issues.apache.org/jira/browse/OAK-75
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mk
>Reporter: Stefan Guggisberg
> Attachments: OAK-83.patch
>
>
> the following MicroKernel methods contain a 'filter' string parameter:
> - getJournal
> - diff
> - getNodes
> through the filter an API client could e.g. specify:
> - special 'meta' properties to be included (e.g. ":hash")
> - glob patterns on the names of properties/child nodes to be included/excluded
> - path filter (for getJournal and diff)
> format/detailed semantics TBD, here's an initial proposal (json):
> {code}
> {
> "path" : "/some/path",
> "incl" : [ ":hash", "*" ],
> "excl" : [ "tmp*" ]
> }
> {code}
> name filter patterns should ideally be the same
> format as specified for JCR Node.getNodes/getProperties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (OAK-75) specify format and semantics of 'filter' parameter in MicroKernel API
[
https://issues.apache.org/jira/browse/OAK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13281630#comment-13281630
]
Stefan Guggisberg edited comment on OAK-75 at 5/23/12 2:41 PM:
---
{noformat}
added initial support for glob-based getNodes filter in svn r1341873.
the format is as suggested by michael. however, since \ (backslash) needs to be
escaped in json (leading to pretty awkward java strings such as e.g.
"{nodes:[\"foo*\"]}"}) i've chosen to require the literal * to be escaped
instead of the wildcard.
Glob Syntax:
a nodes or properties filter consists of one or more globs.
a glob prefixed by - (dash) is treated as an exclusion pattern; all others are
considered inclusion patterns.
a leading - (dash) must be escaped by prepending \ (backslash) if it should be
interpreted as a literal.
* (asterisk) serves as a wildcard, i.e. it matches any substring in the target
name.
* (asterisk) occurrences within the glob to be interpreted as literals must be
escaped by prepending \ (backslash).
a filter matches a target name if any of the inclusion patterns match but none
of the exclusion patterns.
{noformat}
was (Author: stefan@jira):
{noformat}
added initial support for glob-based getNodes filter in svn r1341873.
the format is as suggested by michael. however, since \ (backslash) needs to be
escaped in json (leading to pretty awkward java strings such as e.g.
"{nodes:[\"foo*\"]}"}) i've chosen to require the literal * to be escaped
instead of the wildcard.
Glob Syntax:
a nodes or properties filter consists of one or more globs.
a glob prefixed by - (dash) is treated as an exclusion pattern; all others are
considered inclusion patterns.
a leading - (dash) must be escaped by prepending \ (backslash) if it should be
interpreted as a literal.
* (asterisk) serves as a wildcard, i.e. it matches any substring in the target
name.
* (asterisk) occurrences within the glob to be interpreted as literals must be
escaped by prepending \ (backslash).
a filter matches a target name if any of the inclusion patterns match but none
of the exclusion patterns.
> specify format and semantics of 'filter' parameter in MicroKernel API
> -
>
> Key: OAK-75
> URL: https://issues.apache.org/jira/browse/OAK-75
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mk
>Reporter: Stefan Guggisberg
> Attachments: OAK-83.patch
>
>
> the following MicroKernel methods contain a 'filter' string parameter:
> - getJournal
> - diff
> - getNodes
> through the filter an API client could e.g. specify:
> - special 'meta' properties to be included (e.g. ":hash")
> - glob patterns on the names of properties/child nodes to be included/excluded
> - path filter (for getJournal and diff)
> format/detailed semantics TBD, here's an initial proposal (json):
> {code}
> {
> "path" : "/some/path",
> "incl" : [ ":hash", "*" ],
> "excl" : [ "tmp*" ]
> }
> {code}
> name filter patterns should ideally be the same
> format as specified for JCR Node.getNodes/getProperties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (OAK-75) specify format and semantics of 'filter' parameter in MicroKernel API
[
https://issues.apache.org/jira/browse/OAK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13281630#comment-13281630
]
Stefan Guggisberg edited comment on OAK-75 at 5/23/12 2:40 PM:
---
{noformat}
added initial support for glob-based getNodes filter in svn r1341873.
the format is as suggested by michael. however, since \ (backslash) needs to be
escaped in json (leading to pretty awkward java strings such as e.g.
"{nodes:[\"foo*\"]}"}) i've chosen to require the literal * to be escaped
instead of the wildcard.
Glob Syntax:
a nodes or properties filter consists of one or more globs.
a glob prefixed by - (dash) is treated as an exclusion pattern; all others are
considered inclusion patterns.
a leading - (dash) must be escaped by prepending \ (backslash) if it should be
interpreted as a literal.
* (asterisk) serves as a wildcard, i.e. it matches any substring in the target
name.
* (asterisk) occurrences within the glob to be interpreted as literals must be
escaped by prepending \ (backslash).
a filter matches a target name if any of the inclusion patterns match but none
of the exclusion patterns.
was (Author: stefan@jira):
added initial support for glob-based getNodes filter in svn r1341873.
the format is as suggested by michael. however, since {noformat}\{noformat}
(backslash) needs to be escaped in json (leading to pretty awkward java strings
such as e.g. {noformat}"{nodes:[\"foo*\"]}"}{noformat}) i've chosen to
require the literal * to be escaped instead of the wildcard.
{noformat}
Glob Syntax:
a nodes or properties filter consists of one or more globs.
a glob prefixed by - (dash) is treated as an exclusion pattern; all others are
considered inclusion patterns.
a leading - (dash) must be escaped by prepending \ (backslash) if it should be
interpreted as a literal.
* (asterisk) serves as a wildcard, i.e. it matches any substring in the target
name.
* (asterisk) occurrences within the glob to be interpreted as literals must be
escaped by prepending \ (backslash).
a filter matches a target name if any of the inclusion patterns match but none
of the exclusion patterns.
{noformat}
> specify format and semantics of 'filter' parameter in MicroKernel API
> -
>
> Key: OAK-75
> URL: https://issues.apache.org/jira/browse/OAK-75
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mk
>Reporter: Stefan Guggisberg
> Attachments: OAK-83.patch
>
>
> the following MicroKernel methods contain a 'filter' string parameter:
> - getJournal
> - diff
> - getNodes
> through the filter an API client could e.g. specify:
> - special 'meta' properties to be included (e.g. ":hash")
> - glob patterns on the names of properties/child nodes to be included/excluded
> - path filter (for getJournal and diff)
> format/detailed semantics TBD, here's an initial proposal (json):
> {code}
> {
> "path" : "/some/path",
> "incl" : [ ":hash", "*" ],
> "excl" : [ "tmp*" ]
> }
> {code}
> name filter patterns should ideally be the same
> format as specified for JCR Node.getNodes/getProperties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (OAK-75) specify format and semantics of 'filter' parameter in MicroKernel API
[
https://issues.apache.org/jira/browse/OAK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13281630#comment-13281630
]
Stefan Guggisberg edited comment on OAK-75 at 5/23/12 2:38 PM:
---
added initial support for glob-based getNodes filter in svn r1341873.
the format is as suggested by michael. however, since {noformat}\{noformat}
(backslash) needs to be escaped in json (leading to pretty awkward java strings
such as e.g. {noformat}"{nodes:[\"foo*\"]}"}{noformat}) i've chosen to
require the literal * to be escaped instead of the wildcard.
{noformat}
Glob Syntax:
a nodes or properties filter consists of one or more globs.
a glob prefixed by - (dash) is treated as an exclusion pattern; all others are
considered inclusion patterns.
a leading - (dash) must be escaped by prepending \ (backslash) if it should be
interpreted as a literal.
* (asterisk) serves as a wildcard, i.e. it matches any substring in the target
name.
* (asterisk) occurrences within the glob to be interpreted as literals must be
escaped by prepending \ (backslash).
a filter matches a target name if any of the inclusion patterns match but none
of the exclusion patterns.
{noformat}
was (Author: stefan@jira):
added initial support for glob-based getNodes filter in svn r1341873.
the format is as suggested by michael. however, since {{{\}}} (backslash) needs
to be escaped in json (leading to pretty awkward java strings such as e.g.
{{{"{nodes:[\"foo*\"]}"}}}) i've chosen to require the literal * to be
escaped instead of the wildcard.
{{{
Glob Syntax:
a nodes or properties filter consists of one or more globs.
a glob prefixed by - (dash) is treated as an exclusion pattern; all others are
considered inclusion patterns.
a leading - (dash) must be escaped by prepending \ (backslash) if it should be
interpreted as a literal.
* (asterisk) serves as a wildcard, i.e. it matches any substring in the target
name.
* (asterisk) occurrences within the glob to be interpreted as literals must be
escaped by prepending \ (backslash).
a filter matches a target name if any of the inclusion patterns match but none
of the exclusion patterns.
}}}
> specify format and semantics of 'filter' parameter in MicroKernel API
> -
>
> Key: OAK-75
> URL: https://issues.apache.org/jira/browse/OAK-75
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mk
>Reporter: Stefan Guggisberg
> Attachments: OAK-83.patch
>
>
> the following MicroKernel methods contain a 'filter' string parameter:
> - getJournal
> - diff
> - getNodes
> through the filter an API client could e.g. specify:
> - special 'meta' properties to be included (e.g. ":hash")
> - glob patterns on the names of properties/child nodes to be included/excluded
> - path filter (for getJournal and diff)
> format/detailed semantics TBD, here's an initial proposal (json):
> {code}
> {
> "path" : "/some/path",
> "incl" : [ ":hash", "*" ],
> "excl" : [ "tmp*" ]
> }
> {code}
> name filter patterns should ideally be the same
> format as specified for JCR Node.getNodes/getProperties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-99) reading binary content fails for certain types of content
[ https://issues.apache.org/jira/browse/OAK-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated OAK-99: - Component/s: (was: mk) core it's not a MicroKernel issue and not related to MVP. it's seems to be caused by how PropertyType.BINARY properties are internally represented in oak-core. o.a.j.oak.kernel.BinaryValue expects the property value to be the blobId and the real data is retrieved by calling MicroKernel.read(blobId, ...); the exception is thrown because the value is not a blobId (hex format); it's a base64 format string. it could be that small binary values are inlined (which perfectly makes sense) but BinaryValue is not aware of inlined values and always expects a blobId. > reading binary content fails for certain types of content > - > > Key: OAK-99 > URL: https://issues.apache.org/jira/browse/OAK-99 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Julian Reschke > > With r1336746 I have added test content for export tests; and get the failure > below: > org.apache.jackrabbit.mk.api.MicroKernelException: > org.apache.jackrabbit.mk.api.MicroKernelException: SGVsbG8gd8O2cmxkLg== > at > org.apache.jackrabbit.mk.core.MicroKernelImpl.read(MicroKernelImpl.java:490) > at > org.apache.jackrabbit.mk.util.MicroKernelInputStream.read(MicroKernelInputStream.java:56) > at java.io.InputStream.read(Unknown Source) > at org.apache.jackrabbit.util.Base64.encode(Base64.java:156) > at org.apache.jackrabbit.value.ValueHelper.serialize(ValueHelper.java:681) > at > org.apache.jackrabbit.commons.xml.SystemViewExporter.exportValue(SystemViewExporter.java:129) > at > org.apache.jackrabbit.commons.xml.SystemViewExporter.exportProperty(SystemViewExporter.java:109) > at > org.apache.jackrabbit.commons.xml.Exporter.exportProperty(Exporter.java:361) > at > org.apache.jackrabbit.commons.xml.Exporter.exportProperties(Exporter.java:268) > at > org.apache.jackrabbit.commons.xml.SystemViewExporter.exportNode(SystemViewExporter.java:77) > at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:294) > at org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:213) > at > org.apache.jackrabbit.commons.xml.SystemViewExporter.exportNode(SystemViewExporter.java:78) > at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:294) > at org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:213) > at > org.apache.jackrabbit.commons.xml.SystemViewExporter.exportNode(SystemViewExporter.java:78) > at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:294) > at org.apache.jackrabbit.commons.xml.Exporter.exportNodes(Exporter.java:213) > at > org.apache.jackrabbit.commons.xml.SystemViewExporter.exportNode(SystemViewExporter.java:78) > at org.apache.jackrabbit.commons.xml.Exporter.exportNode(Exporter.java:294) > at org.apache.jackrabbit.commons.xml.Exporter.export(Exporter.java:143) > at > org.apache.jackrabbit.commons.AbstractSession.export(AbstractSession.java:548) > at > org.apache.jackrabbit.commons.AbstractSession.exportSystemView(AbstractSession.java:257) > at > org.apache.jackrabbit.test.api.ExportSysViewTest.doTestWithHandler(ExportSysViewTest.java:126) > at > org.apache.jackrabbit.test.api.ExportSysViewTest.testExportSysView_handler_session_saveBinary_recurse(ExportSysViewTest.java:94) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > at junit.framework.TestCase.runTest(TestCase.java:168) > at junit.framework.TestCase.runBare(TestCase.java:134) > at junit.framework.TestResult$1.protect(TestResult.java:110) > at junit.framework.TestResult.runProtected(TestResult.java:128) > at junit.framework.TestResult.run(TestResult.java:113) > at junit.framework.TestCase.run(TestCase.java:124) > at org.apache.jackrabbit.test.AbstractJCRTest.run(AbstractJCRTest.java:456) > at junit.framework.TestSuite.runTest(TestSuite.java:243) > at junit.framework.TestSuite.run(TestSuite.java:238) > at junit.framework.TestSuite.runTest(TestSuite.java:243) > at junit.framework.TestSuite.run(TestSuite.java:238) > at junit.framework.TestSuite.runTest(TestSuite.java:243) > at > org.apache.jackrabbit.test.ConcurrentTestSuite.access$1(ConcurrentTestSuite.java:1) > at > org.apache.jackrabbit.test.ConcurrentTestSuite$2.run(ConcurrentTestSuite.java:67) > at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) > Caused by: org.apache.jackrabbit.mk.api.MicroKernelException: > SGVsbG8gd8O2cmxkLg
[jira] [Resolved] (OAK-85) NPE and wrong result on copy operation
[
https://issues.apache.org/jira/browse/OAK-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved OAK-85.
--
Resolution: Fixed
Fix Version/s: 0.3
fixed in svn r1334040
> NPE and wrong result on copy operation
> --
>
> Key: OAK-85
> URL: https://issues.apache.org/jira/browse/OAK-85
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mk
>Affects Versions: 0.1
>Reporter: Michael Dürig
>Assignee: Stefan Guggisberg
> Fix For: 0.3
>
>
> {code}
> mk.commit("", "+\"/root\":{}", null, null);
> mk.commit("", "+\"/root/N4\":{} *\"/root/N4\":\"/root/N4/N5\"", null, null);
> {code}
> results in a NPE. Doing all operations separately instead gives the wrong
> result:
> {code}
> mk.commit("", "+\"/root\":{}", null, null);
> mk.commit("", "+\"/root/N4\":{}", null, null);
> mk.commit("", "*\"/root/N4\":\"/root/N4/N5\"", null, null);
> {code}
> results in (relative to /root)
> {code}
> {
> ":childNodeCount": 1,
> "N4": {
> ":childNodeCount": 1,
> "N5": {
> ":childNodeCount": 1,
> "N5": {
> ":childNodeCount": 0
> }
> }
> }
> }
> {code}
> instead of
> {code}
> {
> ":childNodeCount": 1,
> "N4": {
> ":childNodeCount": 0,
> "N5": {
> ":childNodeCount": 0
> }
> }
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OAK-85) NPE and wrong result on copy operation
[
https://issues.apache.org/jira/browse/OAK-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned OAK-85:
Assignee: Stefan Guggisberg
> NPE and wrong result on copy operation
> --
>
> Key: OAK-85
> URL: https://issues.apache.org/jira/browse/OAK-85
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mk
>Affects Versions: 0.1
>Reporter: Michael Dürig
>Assignee: Stefan Guggisberg
>
> {code}
> mk.commit("", "+\"/root\":{}", null, null);
> mk.commit("", "+\"/root/N4\":{} *\"/root/N4\":\"/root/N4/N5\"", null, null);
> {code}
> results in a NPE. Doing all operations separately instead gives the wrong
> result:
> {code}
> mk.commit("", "+\"/root\":{}", null, null);
> mk.commit("", "+\"/root/N4\":{}", null, null);
> mk.commit("", "*\"/root/N4\":\"/root/N4/N5\"", null, null);
> {code}
> results in (relative to /root)
> {code}
> {
> ":childNodeCount": 1,
> "N4": {
> ":childNodeCount": 1,
> "N5": {
> ":childNodeCount": 1,
> "N5": {
> ":childNodeCount": 0
> }
> }
> }
> }
> {code}
> instead of
> {code}
> {
> ":childNodeCount": 1,
> "N4": {
> ":childNodeCount": 0,
> "N5": {
> ":childNodeCount": 0
> }
> }
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (OAK-75) specify format and semantics of 'filter' parameter in MicroKernel API
[
https://issues.apache.org/jira/browse/OAK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13268385#comment-13268385
]
Stefan Guggisberg edited comment on OAK-75 at 5/4/12 2:05 PM:
--
> Would that also be the case if we only add the (path-) filter at
> getRevisionHistory, and keep waitForCommit and getHeadRevision as they are
> now?
i've attached a new proposal (see OAK-75.patch):
- changed the 'filter' parameter on getJournal and diff to 'path'
- added a 'path' parameter to getRevisionHistory
- getNodes is the only method providing a 'filter' parameter
open questions:
- globbing syntax for filter needs to be specified. '*' is a legal name
character...
- should we allow for node name filtering as well?
- if yes, do we need to specify separate filters for properties and node names?
- the implicit default filter needs to specified (e.g. { incl: [ "*",
":childNodeCount" ], excl: [ ":hash" ] }
was (Author: stefan@jira):
> Would that also be the case if we only add the (path-) filter at
getRevisionHistory, and keep waitForCommit and getHeadRevision as they are now?
i've attached a new proposal (see OAK-83.patch):
- changed the 'filter' parameter on getJournal and diff to 'path'
- added a 'path' parameter to getRevisionHistory
- getNodes is the only method providing a 'filter' parameter
open questions:
- globbing syntax for filter needs to be specified. '*' is legal name
character...
- should we allow for node name filtering as well?
- if yes, do we need to specify separate filters for properties and node names?
- the implicit default filter needs to specified (e.g. { incl: [ "*",
":childNodeCount" ], excl: [ ":hash" ] }
> specify format and semantics of 'filter' parameter in MicroKernel API
> -
>
> Key: OAK-75
> URL: https://issues.apache.org/jira/browse/OAK-75
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mk
>Reporter: Stefan Guggisberg
> Attachments: OAK-83.patch
>
>
> the following MicroKernel methods contain a 'filter' string parameter:
> - getJournal
> - diff
> - getNodes
> through the filter an API client could e.g. specify:
> - special 'meta' properties to be included (e.g. ":hash")
> - glob patterns on the names of properties/child nodes to be included/excluded
> - path filter (for getJournal and diff)
> format/detailed semantics TBD, here's an initial proposal (json):
> {code}
> {
> "path" : "/some/path",
> "incl" : [ ":hash", "*" ],
> "excl" : [ "tmp*" ]
> }
> {code}
> name filter patterns should ideally be the same
> format as specified for JCR Node.getNodes/getProperties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-75) specify format and semantics of 'filter' parameter in MicroKernel API
[
https://issues.apache.org/jira/browse/OAK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13268385#comment-13268385
]
Stefan Guggisberg commented on OAK-75:
--
> Would that also be the case if we only add the (path-) filter at
> getRevisionHistory, and keep waitForCommit and getHeadRevision as they are
> now?
i've attached a new proposal (see OAK-83.patch):
- changed the 'filter' parameter on getJournal and diff to 'path'
- added a 'path' parameter to getRevisionHistory
- getNodes is the only method providing a 'filter' parameter
open questions:
- globbing syntax for filter needs to be specified. '*' is legal name
character...
- should we allow for node name filtering as well?
- if yes, do we need to specify separate filters for properties and node names?
- the implicit default filter needs to specified (e.g. { incl: [ "*",
":childNodeCount" ], excl: [ ":hash" ] }
> specify format and semantics of 'filter' parameter in MicroKernel API
> -
>
> Key: OAK-75
> URL: https://issues.apache.org/jira/browse/OAK-75
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mk
>Reporter: Stefan Guggisberg
> Attachments: OAK-83.patch
>
>
> the following MicroKernel methods contain a 'filter' string parameter:
> - getJournal
> - diff
> - getNodes
> through the filter an API client could e.g. specify:
> - special 'meta' properties to be included (e.g. ":hash")
> - glob patterns on the names of properties/child nodes to be included/excluded
> - path filter (for getJournal and diff)
> format/detailed semantics TBD, here's an initial proposal (json):
> {code}
> {
> "path" : "/some/path",
> "incl" : [ ":hash", "*" ],
> "excl" : [ "tmp*" ]
> }
> {code}
> name filter patterns should ideally be the same
> format as specified for JCR Node.getNodes/getProperties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-75) specify format and semantics of 'filter' parameter in MicroKernel API
[
https://issues.apache.org/jira/browse/OAK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg updated OAK-75:
-
Attachment: OAK-83.patch
proposed MicroKernel API change/clarification
> specify format and semantics of 'filter' parameter in MicroKernel API
> -
>
> Key: OAK-75
> URL: https://issues.apache.org/jira/browse/OAK-75
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mk
>Reporter: Stefan Guggisberg
> Attachments: OAK-83.patch
>
>
> the following MicroKernel methods contain a 'filter' string parameter:
> - getJournal
> - diff
> - getNodes
> through the filter an API client could e.g. specify:
> - special 'meta' properties to be included (e.g. ":hash")
> - glob patterns on the names of properties/child nodes to be included/excluded
> - path filter (for getJournal and diff)
> format/detailed semantics TBD, here's an initial proposal (json):
> {code}
> {
> "path" : "/some/path",
> "incl" : [ ":hash", "*" ],
> "excl" : [ "tmp*" ]
> }
> {code}
> name filter patterns should ideally be the same
> format as specified for JCR Node.getNodes/getProperties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-83) Copy operation would recurse indefinitely if memory permitted
[
https://issues.apache.org/jira/browse/OAK-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved OAK-83.
--
Resolution: Fixed
Fix Version/s: 0.3
fixed in svn r1333899
> Copy operation would recurse indefinitely if memory permitted
> -
>
> Key: OAK-83
> URL: https://issues.apache.org/jira/browse/OAK-83
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mk
>Affects Versions: 0.1
>Reporter: Michael Dürig
>Assignee: Stefan Guggisberg
> Fix For: 0.3
>
>
> {code}
> microKernel.commit("", "*\"/a\":\"/a/b\"", null, null);
> {code}
> causes
> {code}
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOfRange(Arrays.java:3209)
> at java.lang.String.(String.java:215)
> at java.lang.StringBuilder.toString(StringBuilder.java:430)
> at
> org.apache.jackrabbit.oak.commons.PathUtils.concat(PathUtils.java:320)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OAK-83) Copy operation would recurse indefinitely if memory permitted
[
https://issues.apache.org/jira/browse/OAK-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned OAK-83:
Assignee: Stefan Guggisberg
> Copy operation would recurse indefinitely if memory permitted
> -
>
> Key: OAK-83
> URL: https://issues.apache.org/jira/browse/OAK-83
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mk
>Affects Versions: 0.1
>Reporter: Michael Dürig
>Assignee: Stefan Guggisberg
>
> {code}
> microKernel.commit("", "*\"/a\":\"/a/b\"", null, null);
> {code}
> causes
> {code}
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOfRange(Arrays.java:3209)
> at java.lang.String.(String.java:215)
> at java.lang.StringBuilder.toString(StringBuilder.java:430)
> at
> org.apache.jackrabbit.oak.commons.PathUtils.concat(PathUtils.java:320)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> at
> org.apache.jackrabbit.mk.model.CommitBuilder.copyStagedNodes(CommitBuilder.java:293)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-75) specify format and semantics of 'filter' parameter in MicroKernel API
[
https://issues.apache.org/jira/browse/OAK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267469#comment-13267469
]
Stefan Guggisberg commented on OAK-75:
--
> For the one getNodes method, the path is a parameter and could be set in the
> filter as well. Could that lead to confusion?
my intention was to specify the 'path' filter on getJournal() and diff() only.
> I noticed getJournal supports a filter, but the related getRevisionHistory
> not yet. Would it make sense to add the filter to getRevisionHistory as well?
the original idea was to support 'filtering' the 'tree data' (either json or
diff) returned by getJournal, diff and getNodes. since getRevisionHistory
doesn't return tree data i didn't add a filter parameter.
> If we support path filtering in getJournal (I hope we do), should we support
> it in waitForCommit and getHeadRevision as well?
same rationale as for not supporting filters on getRevisionHistory.
but i see your point. i didn't consider supporting path-based filtering on
waitForCommit and getHeadRevision. i wanted to keep the proposal simple and i
am afraid that it will add considerable complexity to the API semantics.
OTOH if there's a real use case in oak-core for such a functionality which
justifies the added complexity of the MK API i am open to extending the current
API.
> specify format and semantics of 'filter' parameter in MicroKernel API
> -
>
> Key: OAK-75
> URL: https://issues.apache.org/jira/browse/OAK-75
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mk
>Reporter: Stefan Guggisberg
>
> the following MicroKernel methods contain a 'filter' string parameter:
> - getJournal
> - diff
> - getNodes
> through the filter an API client could e.g. specify:
> - special 'meta' properties to be included (e.g. ":hash")
> - glob patterns on the names of properties/child nodes to be included/excluded
> - path filter (for getJournal and diff)
> format/detailed semantics TBD, here's an initial proposal (json):
> {code}
> {
> "path" : "/some/path",
> "incl" : [ ":hash", "*" ],
> "excl" : [ "tmp*" ]
> }
> {code}
> name filter patterns should ideally be the same
> format as specified for JCR Node.getNodes/getProperties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-79) Copy operation misses some child nodes
[
https://issues.apache.org/jira/browse/OAK-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved OAK-79.
--
Resolution: Fixed
Fix Version/s: 0.3
fixed in svn r1333455
> Copy operation misses some child nodes
> --
>
> Key: OAK-79
> URL: https://issues.apache.org/jira/browse/OAK-79
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mk
>Affects Versions: 0.1
>Reporter: Michael Dürig
>Assignee: Stefan Guggisberg
> Fix For: 0.3
>
>
> {code}
> microKernel.commit("/", "+\"y\":{}+\"x\":{}", null, null);
> microKernel.commit("/", "+\"x/miss-me\":{} *\"x\":\"y/copy-of-x\"", null,
> null);
> {code}
> results in
> {code}
> {
> ":childNodeCount": 2,
> "y": {
> ":childNodeCount": 1,
> "copy-of-x": {
> ":childNodeCount": 0
> }
> },
> "x": {
> ":childNodeCount": 1,
> "miss-me": {
> ":childNodeCount": 0
> }
> }
> }
> {code}
> instead of
> {code}
> {
> ":childNodeCount": 2,
> "y": {
> ":childNodeCount": 1,
> "copy-of-x": {
> ":childNodeCount": 1,
> "miss-me": {
> ":childNodeCount": 0
> }
> }
> },
> "x": {
> ":childNodeCount": 1,
> "miss-me": {
> ":childNodeCount": 0
> }
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OAK-79) Copy operation misses some child nodes
[
https://issues.apache.org/jira/browse/OAK-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg reassigned OAK-79:
Assignee: Stefan Guggisberg
> Copy operation misses some child nodes
> --
>
> Key: OAK-79
> URL: https://issues.apache.org/jira/browse/OAK-79
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mk
>Affects Versions: 0.1
>Reporter: Michael Dürig
>Assignee: Stefan Guggisberg
>
> {code}
> microKernel.commit("/", "+\"y\":{}+\"x\":{}", null, null);
> microKernel.commit("/", "+\"x/miss-me\":{} *\"x\":\"y/copy-of-x\"", null,
> null);
> {code}
> results in
> {code}
> {
> ":childNodeCount": 2,
> "y": {
> ":childNodeCount": 1,
> "copy-of-x": {
> ":childNodeCount": 0
> }
> },
> "x": {
> ":childNodeCount": 1,
> "miss-me": {
> ":childNodeCount": 0
> }
> }
> }
> {code}
> instead of
> {code}
> {
> ":childNodeCount": 2,
> "y": {
> ":childNodeCount": 1,
> "copy-of-x": {
> ":childNodeCount": 1,
> "miss-me": {
> ":childNodeCount": 0
> }
> }
> },
> "x": {
> ":childNodeCount": 1,
> "miss-me": {
> ":childNodeCount": 0
> }
> }
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-80) Implement batched writing for KernelNodeStore
[ https://issues.apache.org/jira/browse/OAK-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13266538#comment-13266538 ] Stefan Guggisberg commented on OAK-80: -- FWIW: > Personally I'd rather see such batching happening under the MicroKernel API > where the implementation actually knows about things like whether network > roundtrips are involved and what kind of batch sizes are most useful. i imagine that the implementation in the MK would be quite complicated (due to the MVCC contract) whereas supporting batched writes in the upper layer is probably not that difficult. > Implement batched writing for KernelNodeStore > - > > Key: OAK-80 > URL: https://issues.apache.org/jira/browse/OAK-80 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 0.1 >Reporter: Michael Dürig >Assignee: Michael Dürig > > Currently KernelNodeStore and KernelNodeStateBuilder directly apply every > operation on the content tree to the private branch of the Microkernel. There > have been some concerns re. performance hits due to network latency in the > case where the Microkernel is not co-located. > I suggest to add batching capabilities such that operations are only written > through to the Microkernel on certain limits. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-75) specify format and semantics of 'filter' parameter in MicroKernel API
[
https://issues.apache.org/jira/browse/OAK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg updated OAK-75:
-
Description:
the following MicroKernel methods contain a 'filter' string parameter:
- getJournal
- diff
- getNodes
through the filter an API client could e.g. specify:
- special 'meta' properties to be included (e.g. ":hash")
- glob patterns on the names of properties/child nodes to be included/excluded
- path filter (for getJournal and diff)
format/detailed semantics TBD, here's an initial proposal (json):
{code}
{
"path" : "/some/path",
"incl" : [ ":hash", "*" ],
"excl" : [ "tmp*" ]
}
{code}
name filter patterns should ideally be the same
format as specified for JCR Node.getNodes/getProperties.
was:
the following MicroKernel methods contain a 'filter' string parameter:
- getJournal
- diff
- getNodes
through the filter an API client could e.g. specify:
- special 'meta' properties to be included (e.g. ":hash")
- glob patterns on the names of properties/child nodes to be included/excluded
- path filter (for getJournal and diff)
format/detailed semantics TBD, here's an initial proposal (json):
{
"path" : "/some/path",
"incl" : [ ":hash", "*" ],
"excl" : [ "tmp*" ]
}
name filter patterns should ideally be the same
format as specified for JCR Node.getNodes/getProperties.
> specify format and semantics of 'filter' parameter in MicroKernel API
> -
>
> Key: OAK-75
> URL: https://issues.apache.org/jira/browse/OAK-75
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mk
>Reporter: Stefan Guggisberg
>
> the following MicroKernel methods contain a 'filter' string parameter:
> - getJournal
> - diff
> - getNodes
> through the filter an API client could e.g. specify:
> - special 'meta' properties to be included (e.g. ":hash")
> - glob patterns on the names of properties/child nodes to be included/excluded
> - path filter (for getJournal and diff)
> format/detailed semantics TBD, here's an initial proposal (json):
> {code}
> {
> "path" : "/some/path",
> "incl" : [ ":hash", "*" ],
> "excl" : [ "tmp*" ]
> }
> {code}
> name filter patterns should ideally be the same
> format as specified for JCR Node.getNodes/getProperties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-75) specify format and semantics of 'filter' parameter in MicroKernel API
[
https://issues.apache.org/jira/browse/OAK-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg updated OAK-75:
-
Description:
the following MicroKernel methods contain a 'filter' string parameter:
- getJournal
- diff
- getNodes
through the filter an API client could e.g. specify:
- special 'meta' properties to be included (e.g. ":hash")
- glob patterns on the names of properties/child nodes to be included/excluded
- path filter (for getJournal and diff)
format/detailed semantics TBD, here's an initial proposal (json):
{
"path" : "/some/path",
"incl" : [ ":hash", "*" ],
"excl" : [ "tmp*" ]
}
name filter patterns should ideally be the same
format as specified for JCR Node.getNodes/getProperties.
was:
the following MicroKernel methods contain a 'filter' string parameter:
- getJournal
- diff
- getNodes
through the filter an API client could e.g. specify:
- special 'meta' properties to be included (e.g. ":hash")
- glob patterns on the names of properties/child nodes to be included/excluded
- path filter (for getJournal and diff)
format/detailed semantics TBD, here's an initial proposal (json):
{
"path" : "/some/path",
"incl" : [ ":hash", "*" ],
"excl" : [ "tmp*" ]
}
name filter patterns should ideally be the same
format as specified for JCR Node.getNodes/getProperties.
> specify format and semantics of 'filter' parameter in MicroKernel API
> -
>
> Key: OAK-75
> URL: https://issues.apache.org/jira/browse/OAK-75
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mk
>Reporter: Stefan Guggisberg
>
> the following MicroKernel methods contain a 'filter' string parameter:
> - getJournal
> - diff
> - getNodes
> through the filter an API client could e.g. specify:
> - special 'meta' properties to be included (e.g. ":hash")
> - glob patterns on the names of properties/child nodes to be included/excluded
> - path filter (for getJournal and diff)
> format/detailed semantics TBD, here's an initial proposal (json):
>
> {
> "path" : "/some/path",
> "incl" : [ ":hash", "*" ],
> "excl" : [ "tmp*" ]
> }
>
> name filter patterns should ideally be the same
> format as specified for JCR Node.getNodes/getProperties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-75) specify format and semantics of 'filter' parameter in MicroKernel API
Stefan Guggisberg created OAK-75:
Summary: specify format and semantics of 'filter' parameter in
MicroKernel API
Key: OAK-75
URL: https://issues.apache.org/jira/browse/OAK-75
Project: Jackrabbit Oak
Issue Type: New Feature
Components: mk
Reporter: Stefan Guggisberg
the following MicroKernel methods contain a 'filter' string parameter:
- getJournal
- diff
- getNodes
through the filter an API client could e.g. specify:
- special 'meta' properties to be included (e.g. ":hash")
- glob patterns on the names of properties/child nodes to be included/excluded
- path filter (for getJournal and diff)
format/detailed semantics TBD, here's an initial proposal (json):
{
"path" : "/some/path",
"incl" : [ ":hash", "*" ],
"excl" : [ "tmp*" ]
}
name filter patterns should ideally be the same
format as specified for JCR Node.getNodes/getProperties.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-45) Add support for branching and merging of private copies to MicroKernel
[
https://issues.apache.org/jira/browse/OAK-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13262564#comment-13262564
]
Stefan Guggisberg commented on OAK-45:
--
the OOME is not specific to the branch/merge support;
the tests are using the in-mem mk; to avoid the OOME
you can increase the JVM heap size or reduce the number
of commits.
> Add support for branching and merging of private copies to MicroKernel
> --
>
> Key: OAK-45
> URL: https://issues.apache.org/jira/browse/OAK-45
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mk
>Reporter: Michael Dürig
> Attachments: OAK-45__OOME.patch
>
>
> As discussed on the dev list [1] we should add support to the Microkernel for
> branching of a private working copy which can be merged back later:
> {code}
> String addLotsOfData(MicroKernel mk) {
> String baseRevision = mk.getHeadRevision();
> String branchRevision = mk.branch(baseRevision);
> for (int i = 0; i < 100; i++) {
> branchRevision = mk.commit("/", "+\"node" + i + "\":{}",
> branchRevision, null);
> }
> return mk.merge(branchRevision, baseRevision); }
> {code}
> [1] http://markmail.org/message/jbbut6vzvmmjqonr
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-45) Add support for branching and merging of private copies to MicroKernel
[
https://issues.apache.org/jira/browse/OAK-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13261780#comment-13261780
]
Stefan Guggisberg commented on OAK-45:
--
thanks, will investigate
> Add support for branching and merging of private copies to MicroKernel
> --
>
> Key: OAK-45
> URL: https://issues.apache.org/jira/browse/OAK-45
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: mk
>Reporter: Michael Dürig
> Attachments: OAK-45__OOME.patch
>
>
> As discussed on the dev list [1] we should add support to the Microkernel for
> branching of a private working copy which can be merged back later:
> {code}
> String addLotsOfData(MicroKernel mk) {
> String baseRevision = mk.getHeadRevision();
> String branchRevision = mk.branch(baseRevision);
> for (int i = 0; i < 100; i++) {
> branchRevision = mk.commit("/", "+\"node" + i + "\":{}",
> branchRevision, null);
> }
> return mk.merge(branchRevision, baseRevision); }
> {code}
> [1] http://markmail.org/message/jbbut6vzvmmjqonr
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OAK-12) Implement a test suite for the MicroKernel
[ https://issues.apache.org/jira/browse/OAK-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg reassigned OAK-12: Assignee: Stefan Guggisberg > Implement a test suite for the MicroKernel > -- > > Key: OAK-12 > URL: https://issues.apache.org/jira/browse/OAK-12 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: mk >Reporter: Michael Dürig >Assignee: Stefan Guggisberg > Labels: test > > We should have a test suite which thourougly covers the contract of the > MicroKernel API -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
