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
