[jira] [Commented] (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=14592002#comment-14592002
]
Benjamin Lerer commented on CASSANDRA-9532:
---
+1
> 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)
[jira] [Commented] (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=14591734#comment-14591734
]
Sam Tunnicliffe commented on CASSANDRA-9532:
After some further (offline) discussion with [~blerer] we concluded that with
some refactoring around {{Selectable}} & {{SelectorFactories}} we could
probably do away with a separate class to maintain the mappings in 2.2 & trunk.
Rather than block this ticket, I'll open a separate issue to do that. In the
meantime, to preserve the API for {{QueryHandler}} implementors, I've made
{{SelectionColumnMapping}} an interface and renamed it to {{SelectionColumns}},
the idea being that at when we do the refactoring, we'll provide a means of
getting a {{SelectionColumns}} from {{SelectorFactories}}.
> 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)
[jira] [Commented] (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=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)
[jira] [Commented] (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=14589790#comment-14589790
]
Benjamin Lerer commented on CASSANDRA-9532:
---
In my opinion, we should encapsulate the column definitions as part of
{{SelectionColumnMapping}}. It makes sense to keep them together and will
simplify the {{Selection}} code. In 2.2 and trunk we will then be able to
populate {{SelectionColumnMapping}} via
{{SelectorFactories.createFactoriesAndCollectColumnDefinitions}}.
For the {{SelectStatement.getSelection()}} and
{{SelectStatement.getRestrictions}} the javadoc should specify why they are
public. I have the bad habit to remove unused methods.
I think that the method {{SelectionColumnMapping.emptyMapping()}} has a
confusing name. I expected the method to create an immutable empty
{{SelectionColumnMapping}} (like Collections.emptyList()).
> 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)
[jira] [Commented] (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=14580835#comment-14580835
]
Sam Tunnicliffe commented on CASSANDRA-9532:
I've pushed more complete versions for 2.0 through to trunk. As well as the
mods already discussed here, I've made a couple more things accessible that
{{QueryHandler}} impls may want to inspect. These are all related to the
statement's restrictions and/or limit. Where something has been made accessible
that was previously private, I've left the field itself private and added a
public getter. While this is more verbose, I'm wary of the scenario where at
some point in the future, we notice that a public field is never accessed
outside of the class and so switch it back to private, breaking any external
code depending on it. A public method is a clearer indicator of the intent to
expose it.
* trunk
**
[diff|https://github.com/apache/cassandra/compare/trunk...beobal:9532-trunk.patch]
** [unit
tests|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-9532-trunk-testall/]
**
[dtests|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-9532-trunk-dtest/]
* 2.2
**
[diff|https://github.com/apache/cassandra/compare/cassandra-2.2...beobal:9532-2.2.patch]
** [unit
tests|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-9532-2.2-testall/]
**
[dtests|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-9532-2.2-dtest/]
* 2.1
**
[diff|https://github.com/apache/cassandra/compare/cassandra-2.1...beobal:9532-2.1.patch]
** [unit
tests|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-9532-2.1-testall/]
**
[dtests|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-9532-2.1-dtest/]
* 2.0
**
[diff|https://github.com/apache/cassandra/compare/cassandra-2.0...beobal:9532-2.0.patch]
** [unit
tests|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-9532-2.0-testall/]
**
[dtests|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-9532-2.0-dtest/]
> 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: 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)
[jira] [Commented] (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=14579120#comment-14579120
]
mck commented on CASSANDRA-9532:
Working with just 9532-2.0-v2.txt
looks great! thanks heaps. it solves the original ticket description and that
in the
[comment|https://issues.apache.org/jira/browse/CASSANDRA-9532?focusedCommentId=14570398&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14570398]
above.
and the trivial, in SelectionColumnMapping could the \*ColumnMapping\* methods
be shortened to \*Mapping\*, eg{noformat} .addColumnMapping(colSpec, column)
--> .addMapping(colSpec, column)
.addColumnMapping(colSpec, columns) --> .addMapping(colSpec, columns)
.getColumnMappings() --> .getMappings(){noformat}
Only noticed because
{{selectStatement.selection.getColumnMapping().getColumnMappings()}} looked a
little odd at first glance, and maybe
{{selectStatement.selection.getColumnMapping().getMappings()}} would read
better, but it's on the banally trivial side of things.
> 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: 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)
[jira] [Commented] (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=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)
[jira] [Commented] (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 commented on CASSANDRA-9532:
[~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)
[jira] [Commented] (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=14569411#comment-14569411
]
Aleksey Yeschenko commented on CASSANDRA-9532:
--
Don't mind this in principle. Just letting you know that the patch you are
talking about is missing (:
> 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
>
> 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)
[jira] [Commented] (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=14569413#comment-14569413
]
mck commented on CASSANDRA-9532:
jira went down like that minute :-)
> 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
>
> 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)
