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.

example:

// 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"});
session.save();

// 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.


Mime
View raw message