[
https://issues.apache.org/jira/browse/HBASE-14919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15133328#comment-15133328
]
stack commented on HBASE-14919:
-------------------------------
bq. Task #4 in the umbrella issue implements another ImmutableSegment
(CellBlocksSrgment), which does not take MutableSegment on construction.
So, no adapter is necessary in this case? How are they made?
bq. It is possible to do it this way. We believe exposing an unnecessary API
which incurs costly implementation is not advisable.
What you say makes sense. What you think of my continual stumbling over this
ImmutableSegment vs MutableSegment and that there are sometimes Adapters?
bq. This method returns a KeyValueScanner that is used by MemStoreSnapshot, but
it scans the cells in the segment who generated it.
My misunderstanding. Thanks.
bq. Would you like better the name getKeyValueScanner()? And the other method
would be getSegmentScanner().
Yes. This would be clearer I believe.
Thats all my concerns addressed. Let me try and get a basic test run to make
sure basically performs the same but put up a v11 w/ the above small changes
and I'll commit unless objection from others ([~anoop.hbase] or [~enis]).
Thanks [~eshcar].
> Infrastructure refactoring for In-Memory Flush
> ----------------------------------------------
>
> Key: HBASE-14919
> URL: https://issues.apache.org/jira/browse/HBASE-14919
> Project: HBase
> Issue Type: Sub-task
> Affects Versions: 2.0.0
> Reporter: Eshcar Hillel
> Assignee: Eshcar Hillel
> Attachments: HBASE-14919-V01.patch, HBASE-14919-V01.patch,
> HBASE-14919-V02.patch, HBASE-14919-V03.patch, HBASE-14919-V04.patch,
> HBASE-14919-V04.patch, HBASE-14919-V05.patch, HBASE-14919-V06.patch,
> HBASE-14919-V06.patch, HBASE-14919-V07.patch, HBASE-14919-V08.patch,
> HBASE-14919-V09.patch, HBASE-14919-V10.patch
>
>
> Refactoring the MemStore hierarchy, introducing segment (StoreSegment) as
> first-class citizen and decoupling memstore scanner from the memstore
> implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
