Andrew, Today to add a new column we do: admin.disableTable admin.addColumn admin.enableTable
Does the above sequence of operations end up making addColumn *effectively* a sync operation? We do see the newly added columns immediately after admin.enableTable returns at least in our tests that use the mini cluster. The reason I am asking is because we have use cases where we do schema changes when an app server starts up. So subsequent requests expect those schema changes to be there. If we end up removing this *effectively* sync schema change, then we will run into issues because of columns not being present etc. On Friday, November 7, 2014, Andrew Purtell (JIRA) <[email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/PHOENIX-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14202365#comment-14202365 > ] > > Andrew Purtell commented on PHOENIX-1408: > ----------------------------------------- > > bq. Do you think it makes sense to remove our calls to disable the table > before modifying it and doc that the change will take place asynchronously? > We could fix our unit tests easily enough. > > It does indeed make sense, because that's all HBase supports today. > > > > Don't disable table before modifying HTable metadata > > ---------------------------------------------------- > > > > Key: PHOENIX-1408 > > URL: https://issues.apache.org/jira/browse/PHOENIX-1408 > > Project: Phoenix > > Issue Type: Bug > > Reporter: James Taylor > > Assignee: Samarth Jain > > > > In 0.98, HBase supports modifying the HTable metadata without disabling > the table first. We should remove our calls to htable.disableTable() and > htable.enableTable() in ConnectionQueryServicesImpl when we modify the > table metadata. The only time we still need to disable the table is before > we drop it. > > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332) >
