phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-2795) Support auto partition for views
Date Wed, 27 Apr 2016 02:07:12 GMT

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

James Taylor commented on PHOENIX-2795:
---------------------------------------

Thanks for the patch, [~tdsilva]. Here's some feedback:
- What if the view has no where clause, will this be a problem or will there just be no VIEW_STATEMENT
column qualifier?
{code}
+                    byte[] viewStatement = Bytes.toBytes(QueryUtil.getViewStatement(parentTable.getSchemaName().getString(),
parentTable.getTableName().getString(), autoPartionWhere));
+                    for (int i=0; i<cells.size(); ++i) {
+                        cell = cells.get(i);
+                        if (Bytes.equals(cell.getQualifier(), VIEW_STATEMENT_BYTES)) {
+                            cells.remove(i);
+                            viewStatement = Bytes.add(cell.getValue(), Bytes.toBytes(" AND
"), Bytes.toBytes(autoPartionWhere));
+                            break;
+                        }
+                    }
{code}
- In MetaDataEndPointImpl, do you need to search and remove the existing VIEW_STATEMENT and
VIEW_CONSTANT column qualifiers since you're setting them anyway?
{code}
+                    cells = familyCellMap.get(TABLE_FAMILY_BYTES);
+                    cell = null;
+                    for (int i=0; i<cells.size(); ++i) {
+                        cell = cells.get(i);
+                        if (Bytes.equals(cell.getQualifier(), VIEW_CONSTANT_BYTES)) {
+                            cells.remove(i);
+                            break;
+                        }
+                    }
{code}
- If you don't need to remove the column qualifiers explicitly, can you use the MetaDataUtil.getMutationValue()
to look up the cell for VIEW_STATEMENT?
- Minor nit - do we need these new utils or can the existing ones be used? Is it to handle
the multi-tenant case and if so is this a problem elsewhere?
{code}
-    public static Mutation getPutOnlyTableHeaderRow(List<Mutation> tableMetaData) {
+    public static Put getPutOnlyTableHeaderRow(List<Mutation> tableMetaData) {
         for (Mutation m : tableMetaData) {
-            if (m instanceof Put) { return m; }
+            if (m instanceof Put) { return (Put) m; }
         }
-        throw new IllegalStateException("No table header row found in table meatadata");
+        throw new IllegalStateException("No table header row found in table metadata");
+    }
+    
+    public static Put getPutOnlyAutoPartitionColumn(PTable parentTable, List<Mutation>
tableMetaData) {
+        int autoPartitionPutIndex = parentTable.isMultiTenant() ? 2: 1;
+        int i=0;
+        for (Mutation m : tableMetaData) {
+            if (m instanceof Put && i++==autoPartitionPutIndex) { return (Put) m;
}
+        }
+        throw new IllegalStateException("No auto partition column row found in table metadata");
{code}


> Support auto partition for views
> --------------------------------
>
>                 Key: PHOENIX-2795
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-2795
>             Project: Phoenix
>          Issue Type: Sub-task
>            Reporter: James Taylor
>            Assignee: Thomas D'Silva
>              Labels: argus
>             Fix For: 4.8.0
>
>         Attachments: PHOENIX-2795.patch
>
>
> When a view or base table is created, we should have an string AUTO_PARTITION_SEQ parameter
on CREATE TABLE which uses a sequence based on the argument on the server side to generate
a WHERE clause with the first PK column and the unique identifier from the sequence.
> For example:
> {code}
> CREATE SEQUENCE metric_id_seq;
> CREATE TABLE metric_table (metric_id INTEGER, val DOUBLE) AUTO_PARTITION_SEQ=metric_id_seq;
> CREATE VIEW my_view1 AS SELECT * FROM base_table;
> {code}
> would tack on a WHERE clause base on the next value in a sequence, logically like this:
> {code}
> WHERE partition_id =  NEXT VALUE FROM metric_id_seq
> {code}
> It's important that the sequence be generated *after* the check for the existence of
the view so that we don't burn sequence values needlessly if the view already exists.



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

Mime
View raw message