[
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: [email protected]
For additional commands, e-mail: [email protected]
