[
https://issues.apache.org/jira/browse/JCR-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12584112#action_12584112
]
David Rauschenbach commented on JCR-1508:
-----------------------------------------
The only problem with marking this issue as invalid, is that there would be no
acknowledgement that there is a semantic problem in the API. SPI has methods
for discovery of metadata, versus methods for accessing content, and that line
is crossed here.
If I want to write a 10k property, it causes a download of a 1GB property
value, in order to discover metadata only. This is a very basic usability
problem, caused by a semantic gap in the API.
This is not a non-issue for people trying to make this API work in the real
world, who are still your best allies, as long as they haven't given up on it
yet! :-)
At the heart of this issue is also the RuntimeException that my SPI is forced
to throw when a failure occurs during defererencing the value of a property,
which is how I prevent the download of a previous value over a transport. This
RuntimeException is now like those other RuntimeExceptions in JCR2SPI that we
discussed a few months ago, which are all a major problem in the same category,
in my opinion. We are weaving a tangled web, as they say, and it probably all
points to the same semantic gaps in the API, which is causing the impedance
mismatch that would allow all of our methods in the guts of our SPI's or JCR's
to simply have RepositoryExceptions in their method signatures.
> 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.
