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

ASF GitHub Bot commented on DRILL-7604:
---------------------------------------

paul-rogers commented on pull request #1997: DRILL-7604: Allow session options 
to be set in HTTP queries
URL: https://github.com/apache/drill/pull/1997#discussion_r384308531
 
 

 ##########
 File path: 
exec/java-exec/src/main/java/org/apache/drill/exec/server/rest/QueryResources.java
 ##########
 @@ -96,10 +101,13 @@ public QueryResult submitQueryJSON(QueryWrapper query) 
throws Exception {
   @Produces(MediaType.TEXT_HTML)
   public Viewable submitQuery(@FormParam("query") String query,
                               @FormParam("queryType") String queryType,
-                              @FormParam("autoLimit") String autoLimit) throws 
Exception {
+                              @FormParam("autoLimit") String autoLimit,
+                              Form form) throws Exception {
 
 Review comment:
   You have the right idea in general. If we could approve and commit PRs 
quickly, then smaller would absolutely be better. Unfortunately, it typically 
takes a week (sometimes several) to get reviews done.
   
   For historical reasons, commits are done only after running tests on a 
non-public cluster. The folks who have access to that cluster run tests only 
about once a week, typically on Fridays. To reduce work, that person does a 
"batch commit", combines that week's commits into a single branch so tests can 
be run once. It ain't pretty, but it is who things have been done for a long 
time.
   
   If your code conflicts with another PR (such as your own other change in the 
same place), the committer will pick one of them, ask you to resolve conflicts, 
and will then commit the other in the next commit batch a week or two later.
   
   Given our (again, not pretty) process, you are better off combining 
conflicting changes into a single PR.
   
   This is, by the way, why some of my PRs are big: I can't wait months to get 
it done in small pieces the way I "should" do it -- I'd completely forget what 
I was doing several 2-3 week cycles.
   
   We absolutely want to change it, but don't have a good way to run the 
"pre-commit" tests except on that non-public cluster.
   
   Any suggestions you've seen work on other projects?
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


> Cannot set session options using REST API / Web UI
> --------------------------------------------------
>
>                 Key: DRILL-7604
>                 URL: https://issues.apache.org/jira/browse/DRILL-7604
>             Project: Apache Drill
>          Issue Type: Improvement
>          Components: Web Server
>    Affects Versions: 1.17.0
>            Reporter: Dobes Vandermeer
>            Assignee: Dobes Vandermeer
>            Priority: Minor
>
> Some commands are configured using session options that you set using the 
> `SET` command.  However, the `SET` command is not useful in the Web UI and 
> REST API because the options you set are not preserved in the next request.  
> For example, when using CREATE TABLE AS you must `SET store.format csv` to 
> set the output format to comma-separated value, but this is not possible via 
> the REST API.
> I propose that the API be updated to support options that are normally 
> provided using SET:
>  # The JSON API accepts an object "options" whose keys are options and values 
> are option values.  The values should have an appropriate type for the given 
> option, e.g. JSON boolean if the option type is boolean
>  # The form-based API used by the Web UI scans any provided form fields that 
> match a valid session option and sets those options, parsing strings 
> according to the type of option
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to