Julian Reschke wrote:
Marcel Reutegger wrote:
I think your question reveals a design flaw in the batch read method
RepositoryService.getItemInfos(). And it's not just about knowing all
children, it's also about the order of nodes. Even if we are sure we
got all children we still have to call getChildInfos() in case the
parent supports orderable child nodes. Angela, please correct me, if
I'm way off here...
Couldn't we just require that for orderable child nodes, their ItemInfos
are returned in order?
we could, but the issue whether child node infos are complete remains...
Hmmm, does that mean a batch read should also be allowed to return
ChildInfo, with the restriction that it must be complete, when sent?
That would be less expensive than returning ItemInfos for the children.
But would it be useful?
Maybe the more interesting question is, how useful is it to have the distinction
between NodeInfo and ChildInfo?
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.
And how should the SPI implementation know that somebody *wants* to
retrieve all children?
I'm not sure I understand your question, because there is
RepositoryService.getChildInfos(). Do you mean something else?
I was thinking in terms of PROPFIND Depth 0/1, where 1 includes 0. That
is, it's possible to return information about the node and all it's
children, saving yet another round trip. Which may not be sufficient
justification.
But returning ChildInfos will not be sufficient here, because there is
no Batch aspect built in; thus, JCR2SPI still needs to fetch the
ItemInfos for each child node in a separate call.
example content:
/a
/b
/c
Considering the above mentioned method an SPI implementation could return:
NodeInfo(a, [ChildInfo(b), ChildInfo(c)]), NodeInfo(b, []), NodeInfo(c, [])
plus whatever properties are considered useful.
would that work?
regards
marcel
