You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "mck (JIRA)" <ji...@apache.org> on 2015/06/03 10:58:49 UTC

[jira] [Comment Edited] (CASSANDRA-9532) Provide access to select statement's real column definitions

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

mck edited comment on CASSANDRA-9532 at 6/3/15 8:57 AM:
--------------------------------------------------------

[~iamaleksey] is there an easy way of matching requested to real columns? 

selectStatement.selection.columns and resultSet.metadata.names are not always the same size, for example in the query  {code}select name as pop,style,type,country as junk,writetime(style) from music.performers;{code} you'll end up with 4 real columns and 5 requested columns, with only 2 of those columns sharing a name or any obvious way of mapping them together.

If there's no easy way to do it already I can file a new ticket to deal with it (i can probably hack around it as well) but thought i'd bring it up here as it's the natural progression to this ticket.


was (Author: michaelsembwever):
[~iamaleksey] is there an easy way of matching requested to requested columns? Columns and metadata.names are not always the same size. 

> 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)