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

Chris Lohfink commented on CASSANDRA-7464:
------------------------------------------

> Do we need to create KSMetaData and put it into Schema?

I did at the time to prevent a NPE, but that was because I was actually using 
CQL to create the cfmetadata and it looked for the reference in Schema. That 
isnt necessary now though so its good to be removed.

> Do currentScanner / position need to be Atomic?

Absolutely not. Just used it as a wrapper for mutability within lambdas. I 
wanted just a single ISSTableScanner so it could just have the 1 created for 
both list of keys and whole sstable scans. Then the whole thing would not of 
been necessary. But creating the collection of Range<Token>s for the DataRange 
instead of Bounds turned into a mess (there a way of turning Bounds to Range? 
overriding all the Token impls to have a inc/dec etc was intimidating).

> Replace sstable2json and json2sstable
> -------------------------------------
>
>                 Key: CASSANDRA-7464
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7464
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sylvain Lebresne
>            Assignee: Chris Lohfink
>            Priority: Minor
>             Fix For: 3.x
>
>         Attachments: sstable-only.patch, sstabledump.patch
>
>
> Both tools are pretty awful. They are primarily meant for debugging (there is 
> much more efficient and convenient ways to do import/export data), but their 
> output manage to be hard to handle both for humans and for tools (especially 
> as soon as you have modern stuff like composites).
> There is value to having tools to export sstable contents into a format that 
> is easy to manipulate by human and tools for debugging, small hacks and 
> general tinkering, but sstable2json and json2sstable are not that.  
> So I propose that we deprecate those tools and consider writing better 
> replacements. It shouldn't be too hard to come up with an output format that 
> is more aware of modern concepts like composites, UDTs, ....



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to