Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Message-ID: <1745450643.1207038264621.JavaMail.jira@brutus>
Date: Tue, 1 Apr 2008 01:24:24 -0700 (PDT)
From: "Marcel Reutegger (JIRA)" <jira@apache.org>
To: dev@jackrabbit.apache.org
Subject: [jira] Commented: (JCR-1508) Setting a new property value causes a
 read of the previous property value
In-Reply-To: <34087240.1206919224472.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Marcel Reutegger commented on JCR-1508:
---------------------------------------

While constraints may be checked later (i.e. on save), the specification clearly says in setProperty(String name, Value value):

"If the property is multi-valued, a ValueFormatException is thrown."

This exception must be thrown immediately, it cannot be deferred to a later point in time when changes are passed to the SPI implementation.

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