Hey David,
Yep, i'm sure, taking a look at the scan_configuration class, the issue
seems to be here:
Status ScanConfiguration::SetProjectedColumnIndexes(const vector<int>&
col_indexes) {
....
RETURN_NOT_OK*(s->Reset(cols, 0));*
....
In the SetProjectedColumnIndexes method (which is also used by
SetProjectedColumnNames), we're setting the schema without the index.
There are probably a couple of ways to address this:
1. Check if all key columns are in the projection, and if so, maintain
the key.
2. Provide an optional parameter to be able to set the key to users
preference for the new projection. This would be beneficial for cases where
the user may want to create a new table based on their projection.
Thoughts?
Jordan
On Fri, Sep 9, 2016 at 11:08 AM David Alves <[email protected]> wrote:
> Hi Jordan
>
> KuduScanner::GetProjectionSchema returns the schema of the projection
> that was previously set on the scanner. If you don't a projection it should
> indeed return all the columns.
> Are you sure you didn't set a projection (with SetProjectedColumnNames
> or SetProjectedColumnIndexes) that excluded the key?
>
> Best
> David
>
> On Fri, Sep 9, 2016 at 5:16 AM, Jordan Birdsell <[email protected]
> >
> wrote:
>
> > Hey folks,
> >
> > i was doing some work on KUDU-854
> > <https://issues.apache.org/jira/browse/KUDU-854> and when testing the
> > KuduScanner::GetProjectionSchema method call, found that the key was
> being
> > dropped, which makes this much more challenging to test. Any ideas if it
> is
> > intended to drop the key information in a scanner projection? I would
> > imagine this could prevent functionality like creating new tables from a
> > projection.
> >
> > Thanks,
> > Jordan
> >
>
