[ https://issues.apache.org/jira/browse/HDFS-12321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16139360#comment-16139360 ]
Anu Engineer commented on HDFS-12321: ------------------------------------- bq. One thing I found tricky was what's the best way to take arguments from command line for the sql queries. For example if I want to get count of bucket from volume X, but ignoring volumes starts with Y. So we want to take X and Y from command line This is my thought on that, I was planning to create an {code} "args" { "name1": "description of name1", "name2": "description of name2", "name3": "description of name3" } {code} This becomes an args object which we can add to Options as we can verify at the code startup. When we parse the SQL we can only recognise the arguments that are part of the args object. Similarly, when we get command line arguments, we can verify since the SQLCommand and the Args object will tell us what the args is. bq. But I as far as I remember, withLongOpt is specifying the longer version name of the command. For example, x.withLongOpt("createContainer").create("c") means you can type either -c or -createContainer, they both recognized as same createContainer command. If this is correct, then this code snippet is basically keeping overwriting withLongOpt with each of the arguments. Quite possibly you are right on this, My patch is to illustrate the idea, last time we had a discussion you had commented it seemed tricky. bq. Now the issue is, given two argument from command, say M and N, what is the best way to assign the arguments, i.e.whether it is X=M,Y=N or the other way. Ideally, I think they should be specified with options. Such as writing on command line with something like -x M -y N, then we know it is X=M and Y=N. But this means json command file must also provide -x and -y options and how to parse them. This adds some complexity to the code which I was targeting for a separate patch. May be I am missing something here. Let us take a concerte example. Let us say we have two arguments, say volumeName and bucketName in a SQL. These will now become part of args object in JSON as well as part of SQL statement via *:volumeName:* and *:bucketName:*. Now we need to add these two as two options of the command. Before we run the SQL, we have to bind the arguments in the right location (JDBC limitations where this is done via position, so we already remember the arguments positions. So when user runs the command he/she will do it like this-- "hdfs sqlquery commandName -volumeName myVolume -bucketName myBucket" -- inside code we will do a getOption("volumeName") which will return the myVolume to us, which will become part of SQL query. Same thing for bucketName, and sql will contain myBucket. bq. I thought of this too, but it seemed a bit tricky with the Options class. Will need to continue looking closer on how to do this. I was just exploring how hard this would be, and now that we have got a prototype that explores all the JSON to command path and possibly how to deal with args, may be you can drive this to completion? Please let me know if you like me to fix the issues that you have already pointed out. > Ozone : debug cli: add support to load user-provided SQL query > -------------------------------------------------------------- > > Key: HDFS-12321 > URL: https://issues.apache.org/jira/browse/HDFS-12321 > Project: Hadoop HDFS > Issue Type: Sub-task > Reporter: Chen Liang > Assignee: Chen Liang > Fix For: ozone > > Attachments: HDFS-12321-HDFS-7240.001.patch, > HDFS-12321-HDFS-7240.002.patch, HDFS-12321-HDFS-7240.003.patch, > HDFS-12321-HDFS-7240.004.patch, HDFS-12321-HDFS-7240.005.patch, > HDFS-12321-HDFS-7240.006.patch, HDFS-12321-HDFS-7240.007.patch > > > This JIRA extends SQL CLI to support loading a user-provided file that > includes any sql query the user wants to run on the SQLite db obtained by > converting Ozone metadata db. -- This message was sent by Atlassian JIRA (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-issues-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-issues-h...@hadoop.apache.org