[
https://issues.apache.org/jira/browse/CASSANDRA-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117863#comment-15117863
]
Chris Lohfink edited comment on CASSANDRA-7464 at 1/26/16 8:17 PM:
-------------------------------------------------------------------
> 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. New
patch incomming that cleans this up
was (Author: cnlwsu):
> 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)
