[
https://issues.apache.org/jira/browse/SLING-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254033#comment-17254033
]
Miroslav Smiljanic commented on SLING-10011:
--------------------------------------------
Hi [~paul.bjorkstrand], thanks for the comment and analogy with SQL.
Operation we are discussion now is getting the parent node, once we have child
node already.
To continue with the SQL analogy with similar use case, we can have two tables,
customer and order, and suppose we want to get order and customer details for
particular order id.
{code:java}
SELECT c.name, c.city, o.date, o.status FROM `customer` c, `order` o
WHERE c.id = o.customer_id AND o.id = 1
{code}
[http://sqlfiddle.com/#!9/d871f2/5/0|http://sqlfiddle.com/#!9/d871f2/2/0]
||date||status||customer_id||name||city||
|23/11/2020|NEW|1|John|New York|
After executing the query, and obtaining result set item, we have data about
the order but also data from the 'parent' or master table (customer). Customer
data I can get from the same result set item, and it would be wrong to make
another query to do the same thing, this time querying customer table only
{code:java}
SELECT * FROM `customer` c WHERE c.id = 1
{code}
if we go back to JCR domain, Session#getItem(path) would be like executing the
query, and javax.jcr.Item#getParent() similar to obtaining master table data
from result set item after making join table query.
I agree with you that client of the database should not be too concerned with
the implementation details of the query engine and storage. But at the same
time, if there is more than one way to achieve something (get parent node data
in our case), whoever implements client application, should be aware which way
is more appropriate for particular use case.
Problem can be if it is not properly documented. For use case we are discussion
now, probably it should be documented in
[http://jackrabbit.apache.org/oak/docs/dos_and_donts.html]
> Use javax.jcr.Item.getParent() when resolving parent JCR node in
> JcrResourceProvider#getParent
> ----------------------------------------------------------------------------------------------
>
> Key: SLING-10011
> URL: https://issues.apache.org/jira/browse/SLING-10011
> Project: Sling
> Issue Type: Improvement
> Components: JCR
> Affects Versions: JCR Resource 3.0.22
> Reporter: Miroslav Smiljanic
> Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently
> [JcrResourceProvider.getParent|https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/org.apache.sling.jcr.resource-3.0.22/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrResourceProvider.java#L361]
> is using JcrItemResourceFactory.getItemOrNull(String path), which eventually
> is using JCR session to retrieve parent node using absolute path.
> I propose using javax.jcr.Item.getParent() instead.
> Reasoning wold be to utilise potential improvements in JCR implementation
> that would for a given node retrieve the whole subtree. That can be
> configured for example by using particular node type or node path.
> {noformat}
> root
> |
> a
> / \
> b c
> {noformat}
> If node 'a' in picture above, is matching desired configuration, then code
> below would return the whole subtree.
> {code:java}
> Node a = jcrSession.getNode("a");
> {code}
> That further means retrieved subtree can be traversed in memory, without the
> need to communicate with the JCR repository storage.
> (!)That is particularly important when remote (cloud) storage is used for
> repository in JCR implementation, and tree traversal can be done without
> doing additional network roundtrips.
> {code:java}
> //JCR tree traversal happens in memory
> Node b = a.getNode("b");
> Node c = a.getNode("c");
> {code}
> Also going from child to parent, is resolved in memory as well (proposal
> relates to this fact)
> {code:java}
> //JCR tree traversal happens in memory
> assert b.getParent() == c.getParent();
> {code}
> Jackrabbit Oak, for document node store is supporting node bundling for
> configured node type
> [http://jackrabbit.apache.org/oak/docs/nodestore/document/node-bundling.html]
> Currently I am also doing some experiments to support node
> bundling/aggregation for arbitrary node store
> ([NodeDelegateFullyLoaded|https://github.com/smiroslav/jackrabbit-oak/blob/ppnextgen_newstore/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/delegate/NodeDelegateFullyLoaded.java],
>
> [FullyLoadedTree|https://github.com/smiroslav/jackrabbit-oak/blob/ppnextgen_newstore/oak-core/src/main/java/org/apache/jackrabbit/oak/core/FullyLoadedTree.java]).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
