[
https://issues.apache.org/jira/browse/JCR-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584052#action_12584052
]
Julian Reschke commented on JCR-1508:
-------------------------------------
> While constraints may be checked later (i.e. on save), the specification
> clearly says in setProperty(String name, Value value):
Good point. I would argue that we should relax this in JSR-283; it's a
requirement that may be expensive to implement, and gives little benefit.
> This exception must be thrown immediately, it cannot be deferred to a later
> point in time when changes are passed to the SPI implementation.
The SPI implementation could throw the exception while adding the change to the
Batch, couldn't it?
> 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.
