sqoop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Veena Basavaraj (JIRA)" <j...@apache.org>
Subject [jira] [Created] (SQOOP-1652) Submit/Start terminology and SubmissionStatus enums in client and server clarifications
Date Fri, 31 Oct 2014 19:14:33 GMT
Veena Basavaraj created SQOOP-1652:
--------------------------------------

             Summary: 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


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 ? 







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

Mime
View raw message