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: JCR2SPI causes unnecessary getPropertyInfo to obtain primaryType
Date Mon, 17 Mar 2008 15:41:18 GMT
David Rauschenbach wrote:
> I wanted to pass this finding along, just to get it out there.
> 
> After JCR2SPI submits a batch with a new node, it performs a getItemInfos, presumably
to refresh the node and see what server-side items might have been assigned. This ItemInfo
response, by definition, as a NodeInfo at element 0, containing the primaryType of the node.
> 
> If the target server, for whatever reason, opts to NOT include a PropertyInfo for the
jcr:primaryType of the added node, JCR2SPI asks for it by invoking getPropertyInfo. It should
not do so, because the primary type was returned in the NodeInfo.
> 
> In summary, this is more like a design strategy in JCR2SPI. Deteremining a primary type
should be done using the mandatory part of a getItemInfos response (the node info), instead
of using the optional part of a getItemInfos response, which could cause additional I/O for
no good reason.

+0.5.

I'm not too concerned about write performance (yet).

However, I also see calls to getPropertyInfo for 
primarytype/mixintypes/uuid, when the JCR client just calls getProperties().

This really should be avoided; I'd even say that when JCR2SPI already 
has the NodeInfo, getPropertyInfo should never be called for the 
properties defined on nt:base, and optimally also not for jcr:uuid when 
the NodeInfo can already provide it.

Is there a particular reason why JCR2SPI doesn't do that yet? It would 
require some additional code building properties, but I think it would 
be worth it.

BR, Julian

Mime
View raw message