jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Reschke (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1405) SPI: Introduce NodeInfo.getChildInfos()
Date Fri, 22 Feb 2008 20:29:20 GMT

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

Julian Reschke commented on JCR-1405:

> I think you should not even create a NodeInfo in that case. IMO a NodeInfo should be
self contained and shouldn't hold resources tied to the underlying repository.

I disagree with that. 

But anyway, even if it did not an error could occur while building the list of children. I'm
really not sure why we're pretending that things always will work when they may not.

There may be other problems like these (where I currently have to throw unchecked exceptions),
will have to check for that.

> That's actually also a reason why I don't like changing the return values to an Iterator
> Whenever Iterators are returned it implies that an implementation is allowed (or even
encouraged) to lazily retrieve the items. This lazy approach however has some issues. See
also JSR 283 mailing list thread 'I whish there was ....'.

I think it's a feature (to allow lazy construction); we just need to make sure we handle all
cases well.
> This new method is not intended to return large amounts of ChildInfos that are lazily
instanciated and should therefore use an array.

Sounds kind of arbitrary to me. What is "large"? And, if my store doesn't know beforehand
(which one does?), do we really want the SPI impl to return null, just for JCR2PI to asking
for the same information again through a different method call?

> 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