jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Rauschenbach" <david.rauschenb...@synchronica.com>
Subject Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock testassumes that changes in one session are immediately visible in differentsession
Date Tue, 19 Feb 2008 14:56:58 GMT
 
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 {@link #getPropertyIds()}
in
> > +     * conjunction with
> > +     * {@link 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
> > +     * {@link 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
 
 

Mime
View raw message