Details
-
New Feature
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
Description
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.
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.
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)
Validation
Reimplement Script Oak on top of the tooling API.
API draft
- Whiteboard shot of the API entities identified initially.
- Further drafting of the 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.
