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-3534) Add JackrabbitSession.getValueByContentId method
Date Thu, 21 Mar 2013 14:27:15 GMT

    [ 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

View raw message