[
https://issues.apache.org/jira/browse/JCR-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12591972#action_12591972
]
Michael Dürig commented on JCR-1405:
------------------------------------
I'm in favour of the patch as it is. That is, add getChildInfos() to NodeInfo
with the following semantics: If NodeInfo.getChildInfos() returns null, jcr2spi
must call RepositoryService.getChildInfos() to determine the children of the
current node. Otherwise jcr2spi must not (I can also live with 'should not')
call RepositoryService.getChildInfos().
Separate calls to RepositoryService.getChildInfos() result in additional
round-trips in cases where the persistence layer returns the children (infos)
along with a node.
> SPI: Introduce NodeInfo.getChildInfos()
> ---------------------------------------
>
> Key: JCR-1405
> URL: https://issues.apache.org/jira/browse/JCR-1405
> Project: Jackrabbit
> Issue Type: New Feature
> Components: jackrabbit-spi
> Reporter: angela
> Attachments: JCR-1405.patch
>
>
> Improvement suggested by Marcel:
> ChildInfo is basically a stripped down NodeInfo. With little effort it would
> even be possible to have NodeInfo extends ChildInfo. Not sure how useful that
> is, but since we don't have that inheritance in code and at the same time
> nearly a 100% overlap it makes me suspicious.
> Here's another idea:
> introduce a method ChildInfo[] NodeInfo.getChildInfos(). The method either
> returns:
> - all child infos, which also gives the correct number of child nodes. this
> may also mean that an empty array is returned to indicate there are no child
> nodes.
> - null, to indicate that there are *lots* of child nodes and the method
> RepositoryService.getChildInfos() with the iterator should be used.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
