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

Jonathan Ellis commented on CASSANDRA-7464:
-------------------------------------------

bq. my personal preference would be to stop calling that sstable2json, but 
rather have a tool whose purpose is to inspect sstables, since that's what 
people use it for in the first place anyway. That tool could then ultimately 
output multiple formats, json being only one of them and we could have 
something more readable otherwise (and could very well have some more useful 
informations like file offsets and such which could help a lot when debugging

I don't see a point in creating an ad-hoc format along with json.  There's no 
reason we couldn't include file offsets in json.

bq. I'd also personally prefer not re-adding json2sstable. I think that tool is 
a lot less justified since you can easily create sstable (from whatever you 
want) using CQLSSTableWriter.

bq. How about sstabledump? 

+1

> 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
>
>
> 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