jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: SPI caching, was: [jira] Resolved: (JCR-1361) Lock test assumes that changes in one session are immediately visible in different session
Date Tue, 19 Feb 2008 14:06:31 GMT
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();
>  }
> 


Mime
View raw message