I'm going to weigh in somewhere in the middle of Julian and Marcel. 1. Per Marcel's mention of using the NodeInfo to announce whether an SPI is returning ALL or NONE properties (nice grammar, eh), declaring that through the node works for me. In essence, and SPI gets to state whether it would return a level-0, level-1, or level-n response.
2. Per Julian's suggestion, I also support the notion that it's a shame getQNodeTypeDefintions supports a filter, whereas a filter is not supported where it's needed most. 3. Per Julian's other suggestion, I also support the notion of returning MORE data, like number of children, or an IMAP-like \hasChildren flag for Nodes, in case an SPI wanted to declare that a node definitely has no children (so don't ask), or that there are children, but finding out how many is going to cost you. David On Tue, 2008-02-19 at 15:06 +0100, Julian Reschke wrote: > I'm not particularly attached to a specific solution, as long as we make > progress. > > That being said, here are a few comments on the proposal below: > > - what we don't have is an efficient way to query a set of properties, > with the ability for the SPI to return more; similarly to what we do > with getQNodeTypeDefinitions(), > > - we still don't have a cheap way just to retrieve the number of children, > > - we introduce a second way to do something, instead of fixing the one > we already have; so I'd prefer to change getChildInfos so that it can do > what we need (return ItemInfos in addition to ChildInfos, provide the > size without having to build the full result), > > - need a way to throw exceptions. > > Proposal: > > - change the return value of getChildInfos so that size information is > there (Iterator -> RangeIterator or Collection) > > - change the values so that we can return ItemInfos instead of or in > addition to ChildInfos (either by refactoring the class hierarchy so > ItemInfo extends ChildInfo, or by just allowing both types in the Iterator). > > BR, Julian > > > Marcel Reutegger wrote: > > Julian Reschke wrote: > >> Why don't we change things so that ItemInfo *extends* ChildInfo, so > >> that SPI implementations can return NodeInfos as well? JCR2SPI could > >> then use that to update its internal cache, avoiding to refetch the > >> NodeInfos. > > > > I'd rather keep it the way it is right now, but introduce accessors to > > PropertyInfos and ChildInfos on the NodeInfo. As mentioned in a previous > > mail, an implementation would then provide the complete > > Property/ChildInfos or null (if it does not want to batch the > > information or it thinks it is too expensive to do so). I think this > > also nicely aligns with our experience with the bundle persistence > > manager. the overhead of loading property states is usually quickly > > amortized because some of the properties of a node are read in most cases. > > > > regards > > marcel > > > > > > Index: src/main/java/org/apache/jackrabbit/spi/NodeInfo.java > > =================================================================== > > --- src/main/java/org/apache/jackrabbit/spi/NodeInfo.java (revision > > 617369) > > +++ src/main/java/org/apache/jackrabbit/spi/NodeInfo.java (working copy) > > @@ -72,4 +72,31 @@ > > * @see PropertyInfo#getId() > > */ > > public Iterator getPropertyIds(); > > + > > + /** > > + * Returns the property infos of this node info or > > <code>null</code> if none > > + * are provided. If a non-null value is returned an implementation > > must > > + * return the complete list of property infos. If an implemetation > > returns > > + * <code>null</code> a client must use [EMAIL PROTECTED] > > #getPropertyIds()} in > > + * conjunction with > > + * [EMAIL PROTECTED] RepositoryService#getPropertyInfo(SessionInfo, > > PropertyId)} to > > + * retrieve property infos. > > + * > > + * @return Returns the property infos of this node info or > > <code>null</code> > > + * if none are provided. > > + */ > > + public PropertyInfo[] getPropertyInfos(); > > + > > + /** > > + * Returns the child infos of this node info or <code>null</code> > > if none > > + * are provided. If a non-null value is returned an implementation > > must > > + * return the complete list of child infos. If an implementation > > returns > > + * <code>null</code> a client must use > > + * [EMAIL PROTECTED] RepositoryService#getChildInfos(SessionInfo, > > NodeId)} to > > retrieve > > + * the child infos for this node info. > > + * > > + * @return the child infos of this node info or <code>null</code> > > if none > > + * are provided. > > + */ > > + public ChildInfo[] getChildInfos(); > > } > > > Visit Synchronica at GSMA Mobile World Congress, Barcelona, 11-14 Feb, Hall 2, Booth #2J25
