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-1239) SPI: Provide possibility to retrieve the number of child-nodes without retrieving them.
Date Fri, 30 Nov 2007 11:18:43 GMT

    [ https://issues.apache.org/jira/browse/JCR-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547089

Julian Reschke commented on JCR-1239:

> - Is it sufficient if a SPI client calculates the size based on the number of Iterator.next()

I don't think so.

> - This will clearly not work for very large collections. Is it required that we still
want the SPI client to have a way to find out the size?

Yes, I think so.

> - If we need a size information, where does the size belong to?
> - Does it belong to the collection (the parent node) or to the child node entries (currently
the iterator)?
> - Where is such information usually stored, retrieved from? (examples from existing system)

That's hard to tell. Attaching it to the return value of getChildren would have the benefit
to map nicely to what JCR does. Consider SPI2JCR: if the method resides on the parent node,
and a client first calls the new method and *then* gets the children, how would you avoid
calling the JCR getNodes() method twice?

> SPI: Provide possibility to retrieve the number of child-nodes without retrieving them.
> ---------------------------------------------------------------------------------------
>                 Key: JCR-1239
>                 URL: https://issues.apache.org/jira/browse/JCR-1239
>             Project: Jackrabbit
>          Issue Type: Improvement
>          Components: jackrabbit-spi
>            Reporter: angela
>             Fix For: 1.4
> separate issue started by julian within issue #1166:
> RepositoryService.getChildInfos is defined to return an Iterator.
> this forces the caller to loop over all entries in order to detect the number of child-nodes.
> currently the hierarchy is populated any way, but that could be a source for future optimization.
> possible solutions:
> - change return value to RangeIterator
> - change return value to Collection (or Set).

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message