jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1405) SPI: Introduce NodeInfo.getChildInfos()
Date Sat, 23 Feb 2008 09:49:19 GMT

    [ 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:


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

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
- 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...
  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.

> 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.

View raw message