jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1508) Setting a new property value causes a read of the previous property value
Date Mon, 31 Mar 2008 17:26:24 GMT

    [ https://issues.apache.org/jira/browse/JCR-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12583758#action_12583758

angela commented on JCR-1508:

from my point of view the JCR implementation is *required* to check if the new value you want
to set to a property does not conflict with the previous value.


// create a new multivalued property below below an nt:unstructured node:

Node n = session.getRootNode().addNode("myNode", "nt:unstructured");
n.setProperty("aProperty", new String[] {"a", "multi", "value", "property"});

// set another (single) value to the same property
n.setProperty("aProperty", "singlevalued");

this call must from my understanding throw a RepositoryException, because the
PropertyDefinition assigned to the "aProperty" property upon creation is a different
one, then the one that would be assigned if the a single value was passed.
therefore the second call to set property must fail... and i would even argue, that the
client must therefore retrieve the definition of the property...

since currently this is done by retrieving the property (and only loading the definition upon
demand), i think this issue is not valid.

> Setting a new property value causes a read of the previous property value
> -------------------------------------------------------------------------
>                 Key: JCR-1508
>                 URL: https://issues.apache.org/jira/browse/JCR-1508
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: jackrabbit-jcr2spi
>    Affects Versions: 1.4
>            Reporter: David Rauschenbach
> When using JCR2SPI with a custom SPI, getProperty is called when one attempts to set
a new property value with disregard to the previous value. The current JCR2SPI implementation
causes a getPropertyInfo, which requests the old value from the back-end. This is fundamentally
unsound, and kills performance.
> An SPI has no choice but to guard against this by returning a PropertyInfo proxy that
performs lazy-loading of the value. The problem is that if an error occurs when dereferencing
the value, and when performing the lazy-load, JCR2SPI is ill-suited to hande an unchecked
exception at such a time. Besides, it is a "hack upon a hack", because JCR2SPI could do this
work itself, by making proper use of the SPI functions for requesting property type information.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message