On 12.6.12 14:01, Julian Reschke wrote:
Hi there,
seen in SLING (JcrNodeResource.java):
// check stuff for nt:resource (or similar) nodes
if (node.hasProperty(JCR_MIMETYPE)) {
metadata.setContentType(node.getProperty(JCR_MIMETYPE).getString());
}
if (node.hasProperty(JCR_ENCODING)) {
metadata.setCharacterEncoding(node.getProperty(JCR_ENCODING).getString());
}
if (node.hasProperty(JCR_LASTMODIFIED)) {
// We don't check node type, so JCR_LASTMODIFIED might not be a long
final Property prop = node.getProperty(JCR_LASTMODIFIED);
try {
metadata.setModificationTime(prop.getLong());
} catch(ValueFormatException vfe) {
LOGGER.debug("Property {} cannot be converted to a long, ignored ({})",
prop.getPath(), vfe);
}
}
if (node.hasProperty(JCR_DATA)) {
final Property prop = node.getProperty(JCR_DATA);
try {
metadata.setContentLength(prop.getLength());
} catch (ValueFormatException vfe) {
LOGGER.debug(
"Length of Property {} cannot be retrieved, ignored ({})",
prop.getPath(), vfe);
}
}
So instead of just fetching the property, it checks for the presence
first. This seems like a waste of time to me.
Especially since Session.nodeExists() and Node.hasNode() is implemented
by trial and catch... in Jackrabbit core.
Is this just to avoid catching exceptions? (keep in mind that the
exception might be thrown anyway...)
If the concern is that fetching properties that "most of the time" do
not exist would be slow due to exceptions being constructed, then it
might be worthwhile using
Node.getProperties(namepattern)
(which we then could optimized in jackrabbit-core).
I'd prefer to fix this in Jackrabbit core by adding a negative cache (if
this doesn't exist already). A bloom filer would lend itself perfectly here.
Michael
Best regards, Julian
