Maryann and I discussed offline and decided to implement a variant of TableNamespace that returns column family names as pseudo-columns. The type of these pseudo-columns is a struct containing a field for each column in the family. We would need to adjust how we handle ‘select * from t’ and ‘select t.columnFamily.*’, change the validator to disallow ‘select columnFamily from t’, and other fairly minor changes to the validator, and adjust sql-to-rel conversion but once we’re in relational algebra everything should be smooth sailing.
Julian > On Apr 12, 2016, at 10:20 PM, Maryann Xue <[email protected]> wrote: > > Hi, > > Phoenix has a two-level column structure for its tables, first level being > column families and second being columns under each family. We tried modeling > column families as of STRUCT types and columns as fields in their > corresponding STRUCT types. We have now passed parsing and validation, and > columns are represented as a RexFieldAccess (the column) from a RexInputRef > (the column family). > But when executing the query "select * from T", avatica could not handle > STRUCT type and threw an "not implemented" exception at AvaticaSite.java:301. > I was hoping the parser could have flattened this nested structure so that > everything else would just work (both Avatica and Phoenix). For example, a > table having a structure like "VARCHAR K0, RecordType(VARCHAR C0, VARCHAR C1) > F1" can be flattened as "VARCHAR K0, VARCHAR F1.C0, VARCHAR F1.C1". Does that > sound a right direction to head to? > > Otherwise I'm thinking would it be possible to implement column > families/columns as name aliases? Column families in Phoenix are rather meant > for column namespace than having a real nested structure (although they make > a serious difference in HBase), so it would be most desired that they only > exist for column resolving and validation. > > > Thanks, > Maryann
