[
https://issues.apache.org/jira/browse/OAK-6378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16058904#comment-16058904
]
Michael Dürig commented on OAK-6378:
------------------------------------
I like the idea of introducing a {{SegmentWriter}} interface! I think this is
long overdue.
OTOH I'm not to sure about the changes of the return types of the various write
methods. I was experimenting with this myself a while ago and came to a similar
result. What I dislike is the proliferation of various entities (e.g.
{{BlobStore}}) into the record implementations and related classes (e.g.
{{SegmentNodeState}}, {{SegmentNodeBuilder}}). In the end this is the
consequence of those record implementation not being fully stateless. My
preference back then was to better keep this "mess" inside the
{{SegmentWriter}} class instead of spreading it around.
Maybe we could tackle this by going in the opposite direction and have all
{{SegmentWriter}} methods uniformly return a {{Record}} instance? Alternatively
we could try introducing a {{RecordFactory}} and use that one to create
{{Record}} instances from {{RecordId}} s instead of spreading the individual
dependencies?
> Move the SegmentWriter API to its own interface
> -----------------------------------------------
>
> Key: OAK-6378
> URL: https://issues.apache.org/jira/browse/OAK-6378
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segment-tar
> Reporter: Francesco Mari
> Assignee: Francesco Mari
> Fix For: 1.8, 1.7.3
>
>
> In order to isolate {{SegmentWriter}} from the rest of the implementation,
> and to match the corresponding {{SegmentReader}}, I extracted the API exposed
> by {{SegmentWriter}} to its own interface and moved its implementation in a
> separate class.
> Moreover, I cleaned up the {{SegmentWriter}} a bit by letting. every method
> of its interface always return a {{RecordId}}. Before the refactoring, some
> methods returned concrete implementations of record classes. The cleanup
> improves the uniformity of the {{SegmentWriter}} interface.
> I see potential in this change for the following reasons.
> * The concrete record implementations ({{SegmentNodeState}}, {{Template}},
> {{MapRecord}}, etc.) might be implemented directly on top of the
> {{SegmentReader}} and {{SegmentWriter}} API, moved to a different package and
> tested separately from the rest of the code.
> * {{SegmentWrier}} and {{SegmentReader}} provide a higher level API that
> isolates the {{SegmentStore}} and its supporting classes. Code using only
> {{SegmentWriter}} and {{SegmentReader}} might be able to use {{RecordId}}
> instances as opaque handles to the underlying records, with beneficial
> effects on code decoupling.
> I have a working version of the refactoring in [this branch on
> GitHub|https://github.com/francescomari/jackrabbit-oak/tree/segment-writer].
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
