Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <1984270253.1203760159309.JavaMail.jira@brutus>
Date: Sat, 23 Feb 2008 01:49:19 -0800 (PST)
From: "angela (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-1405) SPI: Introduce
 NodeInfo.getChildInfos()
In-Reply-To: <890110651.1203599479619.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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