phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ohad Shacham (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-4232) Hide shadow cell and commit table access in TAL
Date Tue, 26 Sep 2017 17:24:00 GMT


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?


> Hide shadow cell and commit table access in TAL
> -----------------------------------------------
>                 Key: PHOENIX-4232
>                 URL:
>             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

View raw message