[
https://issues.apache.org/jira/browse/CASSANDRA-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14590358#comment-14590358
]
Sam Tunnicliffe commented on CASSANDRA-9532:
--------------------------------------------
Initially I was also keen on encapsulating the column definitions, however
there are a couple of things which complicate that.
* Firstly, aliases belong to {{RawSelector}}, so we would need to extract those
and pass them along with the list of prepared {{Selectable}} to
{{createFactoriesAndCollectColumnDefinitions}} if we are to change that to
collate the {{SelectionColumnMapping}}. This itself is slightly complicated by
the recursive call in {{WithFunction.newSelectorFactory}}, as here {{args}} are
already {{Selectable}} instances. In fact, function arguments cannot be aliased
so it's pretty straightforward to fake up a list of null aliases here but it it
is a bit ugly and so does reduce the net benefit of the refactoring slightly.
* The second issue, also related to the recursive call, is that we would also
collect a mapping & column definition on each recursive call, whereas with the
current patch we only collate for the top-level factories. To illustrate, a
query like {{SELECT ks.function1(col1) FROM ks.table1}} should generate a
single mapping, {{\[ks.function1 -> \[col1\]\]}}. If we combine the
{{selectorFactory}} creation with the collation though, the recursive call in
{{WithFunction.newSelectorFactory}} which processes the args list would
generate another mapping from the {{ColumnIdentifier}} argument, so we'd end up
with {{\[ks.function1 -> \[col1\], col1 -> \[col1\]\]}}. Again, this could be
fixed with a flag to indicate whether to add stuff to the mapping, but I'm not
sure if those two workarounds would destroy the value of refactoring in the
first place.
On the other points, I totally agree and have pushed commits to my dev branches
incorporating them (& rebased the dev branches too).
> Provide access to select statement's real column definitions
> ------------------------------------------------------------
>
> Key: CASSANDRA-9532
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9532
> Project: Cassandra
> Issue Type: Improvement
> Reporter: mck
> Assignee: Sam Tunnicliffe
> Fix For: 3.x, 2.1.x, 2.0.x, 2.2.x
>
> Attachments: 9532-2.0-v2.txt, 9532-2.1-v2.txt, 9532-2.2-v2.txt,
> 9532-trunk-v2.txt, cassandra-2.0-9532.txt, cassandra-2.1-9532.txt,
> cassandra-2.2-9532.txt, trunk-9532.txt
>
>
> Currently there is no way to get access to the real ColumnDefinitions being
> used in a SelectStatement.
> This information is there in
> {{selectStatement.selection.columns}} but is private.
> Giving public access would make it possible for third-party implementations
> of a {{QueryHandler}} to work accurately with the real columns being queried
> and not have to work-around column aliases (or when the rawSelectors don't
> map directly to ColumnDefinitions, eg in Selection.fromSelectors(..), like
> functions), which is what one has to do today with going through
> ResultSet.metadata.names.
> This issue provides a very minimal patch to provide access to the already
> final and immutable fields.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
