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
|