[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:
-----------------------------------
    Description: 
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. 


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 ? 





  was:
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.


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 ? 






> 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: Sub-task
>            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. 
> 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)