You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Michael Dürig (JIRA)" <ji...@apache.org> on 2014/11/03 09:47:34 UTC

[jira] [Commented] (JCR-3311) No mechanism to transparently engage BTreeManager for flat repositories

    [ https://issues.apache.org/jira/browse/JCR-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14194365#comment-14194365 ] 

Michael Dürig commented on JCR-3311:
------------------------------------

As Jackrabbit Oak has OOTB support for flat hierarchies now, this is not a priority any more and I suggest to resolve it as won't fix. 

Also the approach taken by the patch turns out to be problematic as wrapping nodes proliferates to nearly all other JCR classes, which in the end also will need wrapping. 

> No mechanism to transparently engage BTreeManager for flat repositories
> -----------------------------------------------------------------------
>
>                 Key: JCR-3311
>                 URL: https://issues.apache.org/jira/browse/JCR-3311
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-jcr-commons
>    Affects Versions: 2.2, 2.3, 2.4
>            Reporter: David Hausladen
>              Labels: flat, repository
>         Attachments: NodeWrapper.java
>
>
> For someone to enjoy the benefits of the BTreeManager to map between an external, flat path and an internally-branching tree, he must use jackrabbit-specific classes to achieve it.  This is is undesirable.  It would be better if, through configuration, he could specify that his paths are likely flat and Jackrabbit would return implementations of the Node interface that would interact with the BTreeManager internally so that the application code could remain agnostic of the internal challenges of dealing with large numbers of child nodes.
> I've attached NodeWrapper.java which is a preliminary attempt at adapting the Node interface to the BTreeManager.  In practice, however, I found that if the returned, wrapped Nodes were interrogated for their path, they would return the internal, rather than external, paths.  Without an approach to address this problem, I abandoned testing.
> I would not have a problem with an assumption that the configuration option must be chosen at repository creation time and must not be changed thereafter.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)