[jira] [Updated] (SQOOP-1652) Submit/Start terminology and SubmissionStatus enums in client and server clarifications

["Veena Basavaraj (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SQOOP-1652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Veena Basavaraj updated SQOOP-1652:
-----------------------------------
    Fix Version/s:     (was: 1.99.5)
                   2.0.0

> Submit/Start terminology and SubmissionStatus enums in client and server clarifications
> ---------------------------------------------------------------------------------------
>
>                 Key: SQOOP-1652
>                 URL: https://issues.apache.org/jira/browse/SQOOP-1652
>             Project: Sqoop
>          Issue Type: Bug
>            Reporter: Veena Basavaraj
>            Assignee: Veena Basavaraj
>             Fix For: 2.0.0
>
>
> This ticket would like to address 2 broader questions.
> What is the terminology we would want to use for job execution process. 
> There are 2 words very inconsistently used in the code base. Submit/ Start in fact mean 2 different things, there are client/ server apis that use START, but there are error messages and enums communicating status as SUBMITTED in the client and STARTED in other places. 
> Second, Some discussions have alluded that client and the rest API are different? I want to challenge this and ask why ? What is the reasoning for it to be different. It just adds a lot of overhead to think about 2 of these growing apart differently, as a long term contributor to this project, I'd like to minimize this deviation if there is no solid reason to have it that way. To some folks this might look a bit trivial but it will help us not having to debate about things every time we are in this area adding new features. 
> the following using the SERVER status enum
> {code}
> @SuppressWarnings("static-access")
>   public ShowJobStatusFunction() {
>     this.addOption(OptionBuilder.hasArg().withArgName(Constants.OPT_JID)
>        .withDescription(resourceString(Constants.RES_PROMPT_JOB_ID))
>        .withLongOpt(Constants.OPT_JID)
>        .create(Constants.OPT_JID_CHAR));
>   }
>   @Override
>   public Object executeFunction(CommandLine line, boolean isInteractive) {
>     if (line.hasOption(Constants.OPT_JID)) {
>       MSubmission submission = client.getJobStatus(getLong(line, Constants.OPT_JID));
>       if(submission.getStatus().isFailure() || submission.getStatus().equals(SubmissionStatus.SUCCEEDED)) {
>         SubmissionDisplayer.displayHeader(submission);
>         SubmissionDisplayer.displayFooter(submission);
>       } else {
>         SubmissionDisplayer.displayHeader(submission);
>         SubmissionDisplayer.displayProgress(submission);
>       }
>     } else {
>       return null;
>     }
> {code}
> the following startJob in cleint code calls the server status and then uses its OWN enum to decide what to show.
> {code}
>  MSubmission submission = resourceRequests.startJob(jobId).getSubmissions().get(0);
>     while(submission.getStatus().isRunning()) {
>       if(submitted) {
>         invokeSubmissionCallback(callback, submission, SubmissionStatus.SUBMITTED);
>         submitted = false;
>       } else {
>         invokeSubmissionCallback(callback, submission, SubmissionStatus.UPDATED);
>       }
>       Thread.sleep(pollTime);
>       submission = getJobStatus(jobId);
>     }
>     invokeSubmissionCallback(callback, submission, SubmissionStatus.FINISHED);
>     return submission;
>   }
> {code}
> But not having a consistent view of things will lead to confusion down the line when new features are added.
> Similarly we need have our design philosophy around concrete on other things in the code
> 1. How we distinguish between the connector and execution engine responsibilities 
> 2. How we think of the sqoop internal/core behavior vs the API behavior. 
> 3. Repository API: How should it evolve? Should I expose an API to allow nulls in the SQI_INPUT names or should I enforce this in the SQOOP code and not leave it to the decision of the repository implementation
> Today we have unique name constraints in the Derby. How can we enforce such constraints are included in every new implementation we add ? 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)