[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13608975#comment-13608975
]
angela commented on JCR-3534:
-----------------------------
And what I discussed with Felix yesterday as well (again just quick summary of
a longer discussion and pretty much brainstorming
ideas that have not been fully thought through):
the use-case behind the original proposal is basically a shift in paradigm how
we treat and look at a jcr content repository.
in our current 'world' a query "findPropertyWithContentId" would do the trick
and be backed by the current permission model.
however, what the current proposal shadows is the fact that we want to support
a setup where multiple JCR repositories
share resources (such as e.g. the datastore)
in order to address this new way of looking at a content repository and the
interaction between multiple repositories we
should be very clear about the kind of abstraction and concept we want to use.
in addition to marcels summary this basically
has two different flavors:
1) the JCR/Jackrabbit API doesn't not reveal that requirement, the content
repository still behaves the same as before
and we treat that shared datastore (or any other inter-repo-connection) as
implementation detail of the repository not
known nor exposed to the JCR API consumer. in this case we should neither
expose the new proposed method nor
define any public API to access or deal with the datastore.
one possible option to just reflect our requirements with JCR-only API
could be to expose the information stored in the
datastore in a read-only tree underneath /jcr:system such as do for other
repository global information (namespaces,
node types) and access to the individual items would be governed by regular
and possibly fine grained item access.
2) we treat things like the datastore concept as additional repository that was
associated to a given content repository
without being an internal feature of a given implementation. in that case
we may rather want to define a separate API
for the datastore that comes with it's own security concept... depending on
how feature rich this API might get, we
may however end up in situation where we start re-inventing the JCR API for
the data store.... if that was the case
we may rather think on how we could handle such inter-repository
communication or lookup or data-sharing in general
and treat the datastore case as a special case.
in oak we currently are having some sort of intermediate state with a
BlobFactory interface present on the oak-api
which has a lot of unsolved questions associated with it. currently it's just a
'create-only' feature but looking at this
feature request it seems pretty clear to me that there will be pressure to add
additional lookup or query functionality.
whatever we do, we should keep the development in oak in mind in order not to
get locked into a new feature
in jackrabbit core that will cause major troubles in the upcoming jr3 rewrite.
> Add JackrabbitSession.getValueByContentId method
> ------------------------------------------------
>
> Key: JCR-3534
> URL: https://issues.apache.org/jira/browse/JCR-3534
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api, jackrabbit-core
> Affects Versions: 2.6
> Reporter: Felix Meschberger
> Attachments: JCR-3534.patch
>
>
> we have a couple of use cases, where we would like to leverage the global
> data store to prevent sending around and copying around large binary data
> unnecessarily: We have two separate Jackrabbit instances configured to use
> the same DataStore (for the sake of this discussion assume we have the
> problems of concurrent access and garbage collection under control). When
> sending content from one instance to the other instance we don't want to send
> potentially large binary data (e.g. video files) if not needed.
> The idea is for the sender to just send the content identity from
> JackrabbitValue.getContentIdentity(). The receiver would then check whether
> the such content already exists and would reuse if so:
> String ci = contentIdentity_from_sender;
> try {
> Value v = session.getValueByContentIdentity(ci);
> Property p = targetNode.setProperty(propName, v);
> } catch (ItemNotFoundException ie) {
> // unknown or invalid content Identity
> } catch (RepositoryException re) {
> // some other exception
> }
> Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method
> would allow for round tripping the JackrabbitValue.getContentIdentity()
> preventing superfluous binary data copying and moving.
> See also the dev@ thread
> http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
