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

Michael Dürig commented on OAK-6378:
------------------------------------

You are probably right about not hiding those dependencies (e.g. 
{{BlobStore}}). I still dislike them being passed around through those record 
classes just for the sake of ending up at the tip of a call change where they 
are eventually used. However, it is still better than hiding this dependency in 
{{SegmentWriter}}. The note in the {{SegmentWriter.writeNode()}} Javadoc 
actually tells this story. We can try to improve the situation later as I 
proposed before. 

Re. the record-package branch: I like the general direction this is taking. 
Especially decoupling reading from segments from the records and instead going 
through the {{SegmentReader}}. Before going too far with this bit, could you 
check the impact on the benchmarks this is having? I don't expect much but 
then...

> 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)

Reply via email to