[
https://issues.apache.org/jira/browse/JCR-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12571713#action_12571713
]
angela commented on JCR-1405:
-----------------------------
julian:
if you cant determine the childinfos upon creating the nodeinfo you should (as
stated by the javadoc) simply return null,
if you cant build the nodeinfo due to some exceptional situation you should
throw upon getNodeInfo or getItemInfos
respectively.
the exception with repositoryservice getChildInfo means the same as the one
defined with getNodeInfo or getItemInfos:
- the target node does not exist (any more) in the persistent state
- the persistent layer cant be accessed or something similar.
therefore i am with marcels explanation how nodeinfo should be created and work.
in addition, if you decide to do some lazy loading of the childinfos upon
NodeInfo.getChildInfos (or upon RepositoryService.getChildInfos) the exception
from my point of view is not raised upon building the iterator but upon
retrieving the next element.... and there you wont be able to throw repository
exception either.
regarding "large":
this is just one obvious example what could be a reason for the implementation
NOT to reveal
the child infos upon NodeInfo.getChildInfos. and the description mentions this
as example.
that it states: if the impl is not willing.
Not willing means that the SPI implementations decides upon internal rules
whether the
childinfos are included or not. examples: the impl. decides
- based on the internal structure of the persistent layer in general
- based the cost of retrieving childinfos (given the potential chance of never
being asked for)
- based on the known characteristics of the target node: e.g. we have folder
and files and other nodes
and we assume that folders will be used for displaying the children so send
it. for any other nodes we dont
- based on the simple amount of child nodes if we know that (dont calc if more
than 14)
- based on a implementation specific configuration
that could include nodetypes, number of child nodes, day time,
session.userId, random... whatever
you feel would be appropriate, reasonable or simply a good thing for your
specific store.
the last is pretty much what we discussed for the getItemInfos method for the
batch read. we said
that we cant add a config to the spi interfaces and want to leave that to the
impl because we would
not be able to find something that fits the needs for all potential
implementations.
if your store cant retrieve the child info you may
- create your reposervice with a config and leave the decision to someone else
- always calculate the child infos
- never calculate the child infos
- decide based on the characteristics of the requested node
-...
(see above)
so. i am not in favor of adding exceptions to the new method... at least not
for the reasons presented so far.
angela
> 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.
