[
https://issues.apache.org/jira/browse/SQOOP-1626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Veena Basavaraj updated SQOOP-1626:
-----------------------------------
Description:
related to SQOOP-1515
see RB for details
https://reviews.apache.org/r/27196/
For the build-in components we're returning "Sqoop" version that is generated
during the build. It's not necessary a server version, it's just a "release
version".
I think that built-in connectors should return the same version as rest of the
Sqoop as it's a user visible information and having different versioning for
some subcomponents would be really confusing. On the other hand the current way
doesn't seem to be entirely correct - the connector will load the version
information from sqoop-common jar. If I'll upgrade sqoop-common and rest of
Sqoop2, but from some reason I'll leave the old connector jar around it will
report different version then it should. This is something that we should
address in the future through a separate JIRA.
was:
We have different kinds of versions in the Sqoop system. here is a list of them
1. Every configurable has a version that it maintains ( driver has its own
version, connectors have their own version, these are persisted in the
Repository in the SQ_CONFIGURABLE and is exposed in the respective connector
and driver apis
2. We store all the SQOOP entities in the repository which we today support it
using the bare bones Derby schema. This version is also maintained in the
SQ_SYSTEM table and it tells the current schema version we are now in ( the
current schema version is controlled by the SQOOP code)
3. Next we have the actual server version - which is the release version of the
SQOOP such as 1.99.3 or 1.99.4
4. REST API protocol_version - which is v1 today , will be v2 if we
significantly change the apis in next version that are not backwards compatible
5. SHELL /CLIENT version ( not applicable to the clients making web requests,
we should be sending client version only when this request is from CLI possibly)
Before
FROM REST API
{code}
{
revision: "52d5446af0cb63b739c9773efe1d2534ebe20100",
protocols: [
"1"
],
date: "Fri Oct 24 08:09:24 PDT 2014",
user: "vbasavaraj",
url: "git://vbasavaraj.local/Users/vbasavaraj/Projects/sqoop2/common",
version: "2.0.0-SNAPSHOT"
}
{code}
FROM shell
{code}
sqoop:000> show version -all
client version:
Sqoop 2.0.0-SNAPSHOT revision 52d5446af0cb63b739c9773efe1d2534ebe20100
Compiled by vbasavaraj on Fri Oct 24 08:09:24 PDT 2014
server version:
Sqoop 2.0.0-SNAPSHOT revision 52d5446af0cb63b739c9773efe1d2534ebe20100
Compiled by vbasavaraj on Fri Oct 24 08:09:24 PDT 2014
Protocol version:
[1]
sqoop:000>
{code}
The new JSON has the following things
{code}
//todo
{code}
> In built Connectors Version needs to be fixed
> ---------------------------------------------
>
> Key: SQOOP-1626
> URL: https://issues.apache.org/jira/browse/SQOOP-1626
> Project: Sqoop
> Issue Type: Bug
> Reporter: Veena Basavaraj
> Assignee: Veena Basavaraj
> Fix For: 1.99.4
>
>
> related to SQOOP-1515
> see RB for details
> https://reviews.apache.org/r/27196/
> For the build-in components we're returning "Sqoop" version that is generated
> during the build. It's not necessary a server version, it's just a "release
> version".
> I think that built-in connectors should return the same version as rest of
> the Sqoop as it's a user visible information and having different versioning
> for some subcomponents would be really confusing. On the other hand the
> current way doesn't seem to be entirely correct - the connector will load the
> version information from sqoop-common jar. If I'll upgrade sqoop-common and
> rest of Sqoop2, but from some reason I'll leave the old connector jar around
> it will report different version then it should. This is something that we
> should address in the future through a separate JIRA.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
