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

Dinesh Joshi commented on CASSANDRA-7622:
-----------------------------------------

Hey [~cnlwsu],

Here's my feedback on the code so far -
 * {{Schema#getVirtualTable}} - {{containsKey()}} followed by a {{get()}} is 
unnecessary. Using {{get}} will have the same effect.
 * {{VirtualSchema}} - the initializers for {{key}} and {{clustering}} fields 
are unnecessary as you're overwriting them in the constructor. It would be a 
good idea to make the fields final.
 * {{VirtualTable#classFromName}}, {{TableMetaData#virtualClass}} - shouldn't 
the error read differently? VirtualTable strategy class instead of Compaction 
strategy class? Also there is no {{AbstractVirtualColumnFamilyStore}}. Am I 
missing something here?
 * {{InMemoryVirtualTable$SimpleVirtualCommand}} - Use finals for fields
 * {{InMemoryVirtualTable$ResultReadState}} - Use finals for fields
 * {{InMemoryVirtualTable$ResultReadState}} - line 258 - isn't the if check 
redundant?

Nits -
 * {{InMemoryVirtualTable}} - get rid of unused import 
{{org.apache.cassandra.db.marshal.AbstractType;}}

 

> Implement virtual tables
> ------------------------
>
>                 Key: CASSANDRA-7622
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7622
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: CQL
>            Reporter: Tupshin Harper
>            Assignee: Chris Lohfink
>            Priority: Major
>             Fix For: 4.x
>
>
> There are a variety of reasons to want virtual tables, which would be any 
> table that would be backed by an API, rather than data explicitly managed and 
> stored as sstables.
> One possible use case would be to expose JMX data through CQL as a 
> resurrection of CASSANDRA-3527.
> Another is a more general framework to implement the ability to expose yaml 
> configuration information. So it would be an alternate approach to 
> CASSANDRA-7370.
> A possible implementation would be in terms of CASSANDRA-7443, but I am not 
> presupposing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org

Reply via email to