[jira] [Commented] (PHOENIX-1835) Adjust MetaDataEndPointImpl timestamps if table is transactional

["James Taylor (JIRA)" <ji...@apache.org>]

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

James Taylor commented on PHOENIX-1835:
---------------------------------------

[~tdsilva] - another potential way of dealing with the timestamp mismatch is to handle it purely on the client. I'm thinking it might be a bad idea to persist these altered timestamps (x 1000000), as we may attempt to distinguish between transactional data and non transactional data based on the cell timestamp in the future.

Perhaps when we create the TableRef (I think in FromCompiler when we create and resolve the table), we could adjust the value stored in TableRef if the table is transactional.

Let me know if you want me to review how timestamps are managed in Phoenix.

> Adjust MetaDataEndPointImpl timestamps if table is transactional
> ----------------------------------------------------------------
>
>                 Key: PHOENIX-1835
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1835
>             Project: Phoenix
>          Issue Type: Sub-task
>            Reporter: James Taylor
>            Assignee: Thomas D'Silva
>
> Phoenix correlates table metadata with the table data based on timestamp. Since Tephra is adjusting timestamps for the data, we need to do the same for the metadata operations (which aren't transactional through Tephra). Take a look at MetaDataEndPointImpl and the MetaDataMutationResult where we return the server timestamp (i.e. MetaDataMutationResult.getTable() for example). This timestamp should be run through the TransactionUtil.translateTimestamp() method).
> Add a point-in-time test with a table being altered, but your connection being before that time (with CURRENT_SCN) as a test. We'll need to make sure the Puts to the SYSTEM.CATALOG get timestamped correctly (but I think the above will cause that).
> Also, my other hack in PostDDLCompiler, should not be necessary after this:
> {code}
>                         // FIXME: DDL operations aren't transactional, so we're basing the timestamp on a server timestamp.
>                         // Not sure what the fix should be. We don't need conflict detection nor filtering of invalid transactions
>                         // in this case, so maybe this is ok.
>                         if (tableRef.getTable().isTransactional()) {
>                             ts = TransactionUtil.translateMillis(ts);
>                         }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)