[
https://issues.apache.org/jira/browse/SQOOP-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14375993#comment-14375993
]
Veena Basavaraj edited comment on SQOOP-2113 at 3/23/15 10:50 PM:
------------------------------------------------------------------
I thought it was obvious from the prev message, but here is the detailed
explanation.
Initially a value of s config may be null, for instance the case of state
variable generated in the connector. A user might want to edit them to add a
value and this will throw an exception since the record wont even exist, but
when then fetch the configs via the link or job command, they will get all the
configs, even with null values in the list. So it is misleading. Secondly if a
config input is declared for a link or job config, unless the field says not
nullable, a user should be able to store "null" for it and then use that value.
It is semantically correct.
Some of the integration tests were failing "with my patch
because I did not realize that we were not honoring this aspect.
Hope this explains.
Let me even add a concrete example based on the code the is currently present
in the
the value of "lastValue" in the "IncrementRead" will be null, since there is no
value to add to it in the first place. Now the job is kicked off, the jdbc From
code will set the last value and the SQOOP-1803 will try to persist that value
in the Repository using the updateFromJobConfig. It wont work since there is no
such record in the JOB_INPUT table with JOBID and given INPUT ID for the
lastValue.
Should update behave like a UPSERT? well that can be totally avoided by
actually creating the records in the first place.
was (Author: vybs):
I thought it was obvious from the prev message, but here is the detailed
explanation.
Initially a value of s config may be null, for instance the case of state
variable generated in the connector. A user might want to edit them to add a
value and this will throw an exception since the record wont even exist, but
when then fetch the configs via the link or job command, they will get all the
configs, even with null values in the list. So it is misleading. Secondly if a
config input is declared for a link or job config, unless the field says not
nullable, a user should be able to store "null" for it and then use that value.
It is semantically correct.
Some of the integration tests were failing "with my patch
because I did not realize that we were not honoring this aspect.
Hope this explains.
Let me even add a concrete example based on the code the is currently present
in the
the value of "lastValue" in the "IncrementRead" will be null, since there is no
value to add to it in the first place. Now the job is kicked off, the jdbc From
code will set the last value and the SQOOP-1803 will try to persist that value
in the Repository using the updateFromJobConfig. It wont work since there is no
such record in the JOB_INPUT table with JOBID and given INPUT ID for the
lastValue.
> Modify REST API for the RU operation on job and link config
> -----------------------------------------------------------
>
> Key: SQOOP-2113
> URL: https://issues.apache.org/jira/browse/SQOOP-2113
> Project: Sqoop
> Issue Type: Bug
> Reporter: Veena Basavaraj
> Assignee: Veena Basavaraj
> Fix For: 1.99.6
>
> Attachments: SQOOP-2113-1.patch, SQOOP-2113-1.patch,
> SQOOP-2113-2.patch
>
>
> based on the design doc for 1516, support the RU operation on configs for rest
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
