Hi, Reviewed the design in the wiki ( https://cwiki.apache.org/confluence/display/SQOOP/Sqoop+Config+as+Top+Level+Entity ). Thanks for writing such detailed plan. I think its a good idea allow direct editing of configs and the scope of changes look right.
Few questions: 1. In requirements, you mention editing inputs per submission and referred to SQOOP-2025. However, SQOOP-2025 discusses storing history, and I'm not sure it makes sense for history to be editable (well, except for soviet history...). Did you mean to allow editing history? Or are you referring to something else? 2. CLI commands: "show config foo --type JOB --subType from --id 1" I see few possible issues here: 1. I think users don't see config names, so they won't be able to know about "foo" 2. We don't want to use IDs, in CLI (thats an issue across the board, so we may leave it here and fix somewhere else) 3. Having type and subtype seems a bit confusing. Actually, since we don't allow creating configs directly, users may not view them as "first class". In their perspective, they created jobs and links and now they get to view and edit parts of those jobs and links. How about just adding config-type as a filter to the existing job and link commands? "show job --name my_job --config-type from" and "alter job --name my_job --config-type from" This seems to also match the REST API better. Although user facing commands don't have to match REST API. Perhaps others want to chime in here? 3. In REST API, why are we using subType and not type? Is type already used somewhere? 4. Repository changes: Yes! I suspect we need those anyway. Gwen
