[
https://issues.apache.org/jira/browse/PHOENIX-4232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16181177#comment-16181177
]
Ohad Shacham commented on PHOENIX-4232:
---------------------------------------
Thanks [~giacomotaylor].
I looked at Tephra's implementation today.
If we can read different cells and access the commit table from the filter's
logic then we can basically implement a filter, as Tephra guys did, and at the
client side add an attribute with the required info (transaction, shadow cells
suffix, etc...). I assume the htable of the commit table will also need to be
serialized and transferred? Maybe also the one of the original table, in case
it cannot be extracted? Not sure, how large these are and whether it will
degrade performance, however, I assume we will need to do it in any such a case.
This way we will have a general solution (an optimization actually) that can be
used in vanilla Omid and not only when it is used by Phoenix.
We can create a coprocessor and return it at the TAL function "getCoProcessor"
when Omid is used by Phoenix.
What do you think?
Thx,
Ohad
> Hide shadow cell and commit table access in TAL
> -----------------------------------------------
>
> Key: PHOENIX-4232
> URL: https://issues.apache.org/jira/browse/PHOENIX-4232
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Labels: omid
>
> Omid needs to project the shadow cell column qualifier and then based on the
> value, filter the row. If the shadow cell is not found, it needs to perform a
> lookup in the commit table (the source of truth) to get the information
> instead. For the Phoenix integration, there are likely two TAL methods that
> can be added to handle this:
> # Add method call to new TAL method in preScannerOpen call on coprocessor
> that projects the shadow cell qualifiers and sets the time range. This is
> equivalent to the TransactionProcessor.preScannerOpen that Tephra does. It's
> possible this work could be done on the client side as well, but it's more
> likely that the stuff that Phoenix does may override this (but we could get
> it to work if need be).
> # Add TAL method that returns a RegionScanner to abstract out the filtering
> of the row (potentially querying commit table). This RegionScanner would be
> added as the first in the chain in the
> NonAggregateRegionScannerFactory.getRegionScanner() API.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
