[jira] [Commented] (PHOENIX-1489) Access column values positionally from client

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

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

James Taylor commented on PHOENIX-1489:
---------------------------------------

Excellent, [~maryannxue]. I think this'll help the client-side memory footprint and is a better abstraction too. Would you mind holding off on checking in until 4.3 is out (hopefully in a couple of days)? Or check into master, but hold off on 4.0 branch?

Here's some more detailed feedback/questions:
- I noticed a fair amount of serialization/deserialization changes (which is to be expected). Will this be (or can it be made to be) b/w compatible for older 4.2/4.3 clients?
- In ProjectedTableColumnResolver when is the instanceof check needed?
{code}
+    private static class ProjectedTableColumnResolver extends MultiTableColumnResolver {
+        private final boolean isLocalIndex;
+        private final List<TableRef> theTableRefs;
+        private final Map<ColumnRef, Integer> columnRefMap;
+        
+        private ProjectedTableColumnResolver(PTable projectedTable) {
+            super(null, 0);
+            Preconditions.checkArgument(projectedTable.getType() == PTableType.PROJECTED);
+            this.isLocalIndex = projectedTable.getIndexType() == IndexType.LOCAL;
+            this.columnRefMap = new HashMap<ColumnRef, Integer>();
+            long ts = Long.MAX_VALUE;
+            for (PColumn column : projectedTable.getColumns()) {
+                if (!(column instanceof ProjectedColumn))
+                    continue;
+                ColumnRef colRef = ((ProjectedColumn) column).getSourceColumnRef();
+                TableRef tableRef = colRef.getTableRef();
{code}
- Similar question in JoinCompiler. Would it make sense to have a  method on ColumnRef to prevent the instanceof check here:
{code}
@@ -748,76 +739,27 @@ public class JoinCompiler {
                     if (e.getValue() != ColumnRefType.PREFILTER
                             && columnRef.getTableRef().equals(tableRef)
                             && (!retainPKColumns || !SchemaUtil.isPKColumn(columnRef.getColumn()))) {
-                        PColumn column = columnRef.getColumn();
-                        addProjectedColumn(projectedColumns, sourceExpressions, columnNameMap,
-                                column, PNameFactory.newName(TupleProjector.VALUE_COLUMN_FAMILY), hasSaltingColumn,
-                                columnRef instanceof LocalIndexColumnRef, context);
+                        if (columnRef instanceof LocalIndexColumnRef) {
+                            sourceColumns.add(new LocalIndexDataColumnRef(context, IndexUtil.getIndexColumnName(columnRef.getColumn())));
+                        } else {
+                            sourceColumns.add(columnRef);
+                        }
                     }
                 }
             }
{code}
- Minor nit, but can you just start the iteration after the salt column instead of comparing against SALT_COLUMN:
{code}
+        boolean hasSaltingColumn = table.getBucketNum() != null;
+        int position = hasSaltingColumn ? 1 : 0;
+        // Always project PK columns first in case there are some PK columns added by alter table.
+        for (PColumn sourceColumn : table.getPKColumns()) {
+            if (sourceColumn == SALTING_COLUMN)
+                continue;
{code}


> Access column values positionally from client
> ---------------------------------------------
>
>                 Key: PHOENIX-1489
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-1489
>             Project: Phoenix
>          Issue Type: Sub-task
>            Reporter: James Taylor
>            Assignee: Maryann Xue
>         Attachments: 1489-2.patch, 1489-v1.patch
>
>
> Instead of passing back separate KeyValues for data returned from the server, we should access via position using our TupleProjector everywhere. This is already the case for joins and aggregate queries, but not for scan queries. We can modify ScanRegionObserver to use our KeyValueSchema to accomplish this.



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