[
https://issues.apache.org/jira/browse/CASSANDRA-9532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14571363#comment-14571363
]
Sam Tunnicliffe commented on CASSANDRA-9532:
--------------------------------------------
You're right that there isn't currently an easy way to map the columns in the
result metadata to the original/underlying columns that were actually used to
satisfy the query. I've been playing with something similar in this area, which
will hopefully be useful here. I'll clean up the patch (need to tweak it
slightly to work across versions 2.0 -> trunk) and attach it here in the next
day or so.
> 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: mck
> Fix For: 3.x, 2.1.x, 2.0.x, 2.2.x
>
> Attachments: 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)
