> On Nov. 26, 2015, 12:21 p.m., Rajat Khandelwal wrote: > > lens-api/src/main/resources/example-job.xml, lines 27-35 > > <https://reviews.apache.org/r/40638/diff/2/?file=1147004#file1147004line27> > > > > Feels like keeping two conf is only useful when they are present on > > different heirarchies. > > > > If we are creating session just to run a single query, then there is no > > point of having session level and query level configurations. One > > configuration should be enough > > > > Thinking in those terms, an execution shouldn't be a `query`, it should > > be a session. Inside that session there can be multiple actions, which > > might decide the next actions. Any of those actions can be a `query` > > action. > > > > Thoughts? > > Amareshwari Sriramadasu wrote: > I agree there can be many actions in session. But we cannot support each > action through xsd. I think what we can support is List of REST Actions, we > would be generic. Whether we want to support Lens REST actions to be > schedulable or not is something debatable. But can be done later. > > We can start with query as one execution and minimally run on a session > in a db, as it is put up now. > > Coming back to merging session conf and query conf into single one, it > should be fine as long as it is single query, but we should not take away the > fact that query conf can be different for each query when there are multiple > queries. So, I'm fine merging them into one in this jira. > > Rajat Khandelwal wrote: > Considering the important distinction of session conf and query conf, > would the following make more sense? > > ``` > <execution> > <session> > <db>http://192.168.30.30:5000/</db> > <conf> > <key>sessionKey1</key> > <value>sessionValue1</value> > </conf> > </session> > <query> > <query>select name from name_table;</query> > <conf> > <key>queryKey1</key> > <value>queryValue1</value> > </conf> > </query> > </execution> > > ``` > > As a sequence of two actions, open a session with a conf and run a query > with a conf. > > The following might also make sense: > > ``` > <execution> > <session> > <id>session1</id> > <db>http://192.168.30.30:5000/</db> > <conf> > <key>sessionKey1</key> > <value>sessionValue1</value> > </conf> > </session> > <query> > <session_id>session1</session_id> > <query>select name from name_table;</query> > <conf> > <key>queryKey1</key> > <value>queryValue1</value> > </conf> > </query> > </execution> > > ``` > > With this you can open multiple sessions and associate any other action > to take place in any of the sessions. Also, it's more explicit. Here, there > will be an implicit parallel execution of actions of a different sessions. > > > Third option is, we note that any execution will happen in a session, so: > > ``` > <execution> > <!-- begin implicit session conf --> > <db>http://192.168.30.30:5000/</db> > <conf> > <key>sessionKey1</key> > <value>sessionValue1</value> > </conf> > <!-- end implicit session conf --> > <query> > <session_id>session1</session_id> > <query>select name from name_table;</query> > <conf> > <key>queryKey1</key> > <value>queryValue1</value> > </conf> > </query> > </execution> > > ``` > Here, opening multiple sessions will happen thorugh multiple `execution` > tags. > > > Would like to hear the views from implementation and use-case standpoints.
Come to think of it, first and third are functionaly equivalent. - Rajat ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/40638/#review108090 ----------------------------------------------------------- On Nov. 25, 2015, 9:27 p.m., Ajay Yadava wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/40638/ > ----------------------------------------------------------- > > (Updated Nov. 25, 2015, 9:27 p.m.) > > > Review request for lens. > > > Bugs: LENS-879 > https://issues.apache.org/jira/browse/LENS-879 > > > Repository: lens > > > Description > ------- > > Base framework for lens scheduler service and job definition. > > > Diffs > ----- > > lens-api/src/main/java/org/apache/lens/api/query/SchedulerJobHandle.java > PRE-CREATION > > lens-api/src/main/java/org/apache/lens/api/query/SchedulerJobInstanceHandle.java > PRE-CREATION > lens-api/src/main/resources/example-job.xml PRE-CREATION > lens-api/src/main/resources/scheduler-job-0.1.xsd PRE-CREATION > lens-examples/src/main/resources/example-job.xml PRE-CREATION > > lens-server-api/src/main/java/org/apache/lens/server/api/scheduler/JobStats.java > PRE-CREATION > > lens-server-api/src/main/java/org/apache/lens/server/api/scheduler/QuerySchedulerService.java > 9f48d27 > > lens-server-api/src/main/java/org/apache/lens/server/api/scheduler/SchedulerJobInfo.java > PRE-CREATION > > lens-server-api/src/main/java/org/apache/lens/server/api/scheduler/SchedulerJobInstanceInfo.java > PRE-CREATION > > lens-server-api/src/main/java/org/apache/lens/server/api/scheduler/SchedulerService.java > PRE-CREATION > > lens-server/src/main/java/org/apache/lens/server/metrics/MetricsServiceImpl.java > 3389aba > > lens-server/src/main/java/org/apache/lens/server/scheduler/QuerySchedulerServiceImpl.java > 24949bd > > lens-server/src/main/java/org/apache/lens/server/scheduler/SchedulerServiceImpl.java > PRE-CREATION > lens-server/src/main/resources/lensserver-default.xml 5f268cb > > lens-server/src/test/java/org/apache/lens/server/healthcheck/TestHealthChecks.java > e11413e > pom.xml b19857f > src/site/apt/admin/config.apt 88c1489 > > Diff: https://reviews.apache.org/r/40638/diff/ > > > Testing > ------- > > > Thanks, > > Ajay Yadava > >
