jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Francesco Mari (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-6584) Add tooling API
Date Tue, 05 Sep 2017 08:38:01 GMT

    [ https://issues.apache.org/jira/browse/OAK-6584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16153266#comment-16153266

Francesco Mari commented on OAK-6584:

I had a first look at the API. Here are some comments.
# Why {{Store#node}} does not return an {{Optional<Node>}}?
# I think that {{Segment#read}} is too powerful but not as useful. This method allows tooling
to create their own segment parsers, which will never be as complete as the one provided by
the Segment Store.
# {{Segment#header}} looks underspecified. Segment headers are quite easy to model as a proper
interface. I think we should go this way.
# I would like {{Segment#hexDump}} more if it would accept an OutputStream and return void
instead, more like {{o.a.j.o.segment.data.SegmentData#hexDump}}. It might be a matter of personal
taste, though.
# I would rename {{Node#getNodeNames}} and {{Node#getNodes}} to {{Node#childNames}} and {{Node#children}}
# Node is not symmetric with regard to nodes and properties. Why is there {{Node#getNodeNames}}
but not a {{Node#getPropertyNames}}?
# Should {{Node#node}} and {{Node#property}} return {{Optional}} instancesd instead?
# {{Node#NULL_NODE}} and {{Property#NULL_PROPERTY}} could disappear if we returned {{Optional}}
instances consistently.
# I'm not sure if we should allow users of the API to instantiate new {{RecordId}} instances.
Users should be able to navigate the contents of the Segment Store without crafting {{RecordId}}
instances of their own.
# I don't see the usefulness of {{Store#cast}}. For a user to gain something from this method,
he should have a dependency on both the API and a concrete implementation. This defeats the
abstraction layer. In such a situation why not using the concrete implementation directly?
I would remove this method from the API. If the API has shortcomings that are currently addressable
only via {{Store#cast}}, we should take care of them. {{Store#cast}} is too easy to misuse.

> Add tooling API
> ---------------
>                 Key: OAK-6584
>                 URL: https://issues.apache.org/jira/browse/OAK-6584
>             Project: Jackrabbit Oak
>          Issue Type: New Feature
>          Components: segment-tar
>            Reporter: Michael Dürig
>            Assignee: Michael Dürig
>              Labels: tooling
>             Fix For: 1.8
> h3. Current situation
> Current segment store related tools are implemented ad-hoc by potentially relying on
internal implementation details of Oak Segment Tar. This makes those tools less useful, portable,
stable and potentially applicable than they should be.
> h3. Goal
> Provide a common and sufficiently stable Oak Tooling API for implementing segment store
related tools. The API should be independent of Oak and not available for normal production
use of Oak. Specifically it should not be possible to it to implement production features
and production features must not rely on it. It must be possible to implement the Oak Tooling
API in Oak 1.8 and it should be possible for Oak 1.6.
> h3. Typical use cases
> * Query the number of nodes / properties / values in a given path satisfying some criteria
> * Aggregate a certain value on queries like the above
> * Calculate size of the content / size on disk
> * Analyse changes. E.g. how many binaries bigger than a certain threshold were added
/ removed between two given revisions. What is the sum of their sizes?
> * Analyse locality: measure of locality of node states. Incident plots (See https://issues.apache.org/jira/browse/OAK-5655?focusedCommentId=15865973&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15865973).
> * Analyse level of deduplication (e.g. of checkpoint) 
> h3. Validation
> Reimplement [Script Oak|https://github.com/mduerig/script-oak] on top of the tooling
> h3. API draft
> * Whiteboard shot of the [API entities|https://wiki.apache.org/jackrabbit/Oakathon%20August%202017?action=AttachFile&do=view&target=IMG_20170822_163256.jpg]
identified initially.
> * Further [drafting of the API|https://github.com/mduerig/oak-tooling-api] takes place
on Github for now. We'll move to the Apache SVN as soon as considered mature enough and have
a consensus of where to best move it. 

This message was sent by Atlassian JIRA

View raw message