[
https://issues.apache.org/jira/browse/CASSANDRA-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15117772#comment-15117772
]
Yuki Morishita commented on CASSANDRA-7464:
-------------------------------------------
Thanks for the patch.
Pushed your patch + suggestions to
https://github.com/yukim/cassandra/commits/7464.
* We already have getters in SerializationHeader
* I don't want to reference DatabaseDescriptor as much as possible
Questions:
* Do we need to create KSMetaData and put it into Schema?
* Do currentScanner / position need to be Atomic*?
Some more suggestions:
* If we can put the code to open SSTable standalone to, say, SSTableReader, we
can easily reuse it for other offline tools.
* If given key (with '-k') option does not exist in SSTable, stream will
terminate with following error:
{code}
Exception in thread "main" java.util.NoSuchElementException
at
org.apache.cassandra.utils.AbstractIterator.next(AbstractIterator.java:64)
at
org.apache.cassandra.io.sstable.format.big.BigTableScanner.next(BigTableScanner.java:247)
at
org.apache.cassandra.io.sstable.format.big.BigTableScanner.next(BigTableScanner.java:51)
at
org.apache.cassandra.tools.SSTableExport.lambda$main$311(SSTableExport.java:228)
at
org.apache.cassandra.tools.SSTableExport$$Lambda$18/2136288211.apply(Unknown
Source)
at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at
java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
at
java.util.stream.SortedOps$RefSortingSink$$Lambda$20/117009527.accept(Unknown
Source)
at java.util.ArrayList.forEach(ArrayList.java:1249)
at java.util.stream.SortedOps$RefSortingSink.end(SortedOps.java:390)
at java.util.stream.Sink$ChainedReference.end(Sink.java:258)
at java.util.stream.Sink$ChainedReference.end(Sink.java:258)
at java.util.stream.Sink$ChainedReference.end(Sink.java:258)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:513)
at
java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:502)
at
java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at
java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
at
org.apache.cassandra.tools.JsonTransformer.toJson(JsonTransformer.java:76)
at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:255)
{code}
Shouldn't we just skip and continue?
> 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)
