sqoop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Robson <David.Rob...@software.dell.com>
Subject RE: Sqoop documentation
Date Fri, 20 Jun 2014 03:22:37 GMT
Yes it will be a bit confusing for users while there are two connectors - perhaps we should
disable OraOop by default until they are merged into one connector? At least the user will
only have to change a config parameter to use OraOop - where previously they had to install
it.

At the moment they handle things differently as you said - and depending on things like if
there is only one mapper, or if they are importing a view, they will use the default connector.
Could be quite confusing for a user who doesn't understand the reasons why one import has
dates as longs and the other as strings. At least if they have manually installed OraOop in
the past they have read the user's guide so know what to expect.

As part of merging them into one connector we really need to make sure everything is consistent
between the two - I'm thinking this will be a bit of work and I wanted to do it separately
so at least we isolate the QA work to an initial regression test of OraOop. Then we can code
/ test the single connector at a later date.

If we were to document the parameters on the wiki instead of in the documentation - how do
you envisage this would be structured - I can't really see an example of something similar
already on the wiki. It seems like other connectors have put the information directly in the
documentation eg: http://sqoop.apache.org/docs/1.4.4/SqoopUserGuide.html#_microsoft_sql_connector

But the sections are quite short whereas the OraOop one could end up being quite long. It
looks like in Sqoop 2 the documentation will be split into multiple documents - perhaps a
separate page dedicated to all Oracle / Sqoop topics could be included?

-----Original Message-----
From: Gwen Shapira [mailto:gshapira@cloudera.com] 
Sent: Wednesday, 18 June 2014 3:00 PM
To: dev@sqoop.apache.org
Subject: Re: Sqoop documentation

And on similar/different topic:

The biggest risk IMO is that once we add Oraoop as default Oracle manager, users without "select
dictionary" privileges will get "table not found" on jobs that prior to the upgrade were successful.
This breaks backward compatibility in a pretty serious way.

IMO, this has to be fixed before we commit the merge (and yes, I need to add this comment
to the review board)

Gwen


On Tue, Jun 17, 2014 at 9:57 PM, Gwen Shapira <gshapira@cloudera.com> wrote:

> Random thoughts:
>
> The good news is that the first 10 pages ("Installing Oraoop") are 
> redundant.
>
> I'd like to look into cases where the default behavior will change 
> (timestamp processing for instance) and in which case we must amend 
> the current docs.
> In cases where Oraoop offers extra functionality that the users may or 
> may not use (oraoop merge or partitions) we can refer users to a wiki 
> or another external source.
>
> Gwen
>
>
> On Tue, Jun 17, 2014 at 9:26 PM, David Robson < 
> David.Robson@software.dell.com> wrote:
>
>> Hi,
>>
>> I am having a look at how we could integrate the OraOop documentation 
>> into Sqoop. Currently it is a Flare project which we generate a PDF 
>> from - obviously this doesn't really fit in with the current Sqoop documentation.
>>
>> So currently it looks like it is written in asciidoc and converted 
>> into docbook, then into html. We could create an asciidoc file 
>> related to OraOop
>> - the problem is I'm not sure how well this would fit in to the 
>> current documentation - it is already one long page and we would 
>> probably be adding another 20-30 pages worth of content in.
>>
>> You also have a Confluence wiki - we could create a page (or pages) 
>> there with information.
>>
>> What sort of requirements are there for documentation - has someone 
>> got some ideas of how they would like to see the current OraOop 
>> documentation integrated in?
>> https://github.com/QuestSoftwareTCD/OracleSQOOPconnector/blob/master/
>> docs/oraoopuserguide.pdf?raw=true
>>
>> Thanks,
>>
>> David
>>
>
>
Mime
View raw message