Ah actually, it seems there is a broken OraOop test case. Let me see what's going on there before we branch. Jarcec, will you be free around 4PM to branch?
-Abe On Wed, Jul 23, 2014 at 1:19 PM, Abraham Elmahrek <a...@cloudera.com> wrote: > Awesome! Thanks for your hard work guys! > > Jarcec, can we use > https://github.com/apache/sqoop/commit/81624ddf3c8ca5834ab015ebafc8b8649ac36ab7? > In terms of when... let's shoot for 2PM PST? > > -Abe > > > On Wed, Jul 23, 2014 at 12:32 PM, Jarek Jarcec Cecho <jar...@apache.org> > wrote: > >> I think that both are in. Do let me know when and from which commit you >> want me to branch Abe :-) >> >> Jarcec >> >> On Jul 23, 2014, at 10:38 AM, Abraham Elmahrek <a...@cloudera.com> wrote: >> >> > Hey guys, >> > >> > As soon as the Ivy and Avro version changes are in, let's start the >> > branching process? >> > >> > -Abe >> > >> > >> > On Wed, Jul 23, 2014 at 1:02 AM, Venkat Ranganathan < >> > vranganat...@hortonworks.com> wrote: >> > >> >> Generally the number of tasks is a hint to InputFormat.getSplits() >> >> based on number of splits wanted and it can potentially return >> >> different number of splits. >> >> >> >> If you see ExportInputFormat, the split size is determined by >> >> combined file sizes divided by requested num mappers. This is a >> >> integer division and there is a potential for getting additional >> >> splits. >> >> >> >> Thanks >> >> >> >> Venkat >> >> >> >> On Tue, Jul 22, 2014 at 11:41 PM, David Robson >> >> <david.rob...@software.dell.com> wrote: >> >>> Yes OraOop is not enabled by default - and also this particular issue >> is >> >> only when using partitioning - so they would have turned on some extra >> >> flags. Then they also have to be using 1 more mapper than requested as >> you >> >> said - so it's a pretty specific combination of events - so I don't >> think >> >> we need to hold up the release for it. >> >>> >> >>> Do you recall what the behaviour should be in regards to this - the >> >> documentation leads me to believe if we request 4 mappers we should >> get 4 >> >> mappers? If this is only a request and we may get more - perhaps we >> should >> >> update the documentation about this. Otherwise we could change the >> code to >> >> guarantee no more than 4 mappers? >> >>> >> >>> -----Original Message----- >> >>> From: Abraham Elmahrek [mailto:a...@cloudera.com] >> >>> Sent: Wednesday, 23 July 2014 3:16 PM >> >>> To: dev@sqoop.apache.org >> >>> Subject: Re: Final Jiras and Release Date >> >>> >> >>> Hey guys, >> >>> >> >>> AFAIK we can fall back onto the original connector? With that being >> >> said, OraOop is an awesome connector... So i'm completely open to >> waiting >> >> for a fix if it isn't too large. >> >>> >> >>> David, I'm assuming you're referring to the "-m" option? I do recall >> >> some cases where there may be one more split than desired if splitting >> is >> >> not clean. Hopefully Venkat has more insight! >> >>> >> >>> -Abe >> >>> >> >>> >> >>> On Tue, Jul 22, 2014 at 9:42 PM, David Robson < >> >> david.rob...@software.dell.com> wrote: >> >>> >> >>>> Hey Venkat, >> >>>> >> >>>> I had a look into that issue - it seems the problem is even though >> you >> >>>> request 4 mappers - Sqoop runs 5 mappers. Is the number of mappers >> >>>> meant to be guaranteed? For example if I say 4 mappers, should I get >> 4 >> >>>> mappers? I guess there could be potential to get less mappers if the >> >>>> data was for example 1 row - then that would only be processed by 1 >> >>>> mapper. But should it be possible to get more mappers than requested? >> >>>> >> >>>> OraOop is assuming there will be no more mappers than requested - so >> >>>> if this is a valid scenario we would need to modify OraOop. On the >> >>>> other hand if this is unexpected behaviour then we should look at why >> >>>> the num mappers is not working? >> >>>> >> >>>> Either way I don't think we need to fix it for this release - as it >> >>>> seems customers would be unlikely to hit this issue. >> >>>> >> >>>> David >> >>>> >> >>>> -----Original Message----- >> >>>> From: Venkat Ranganathan [mailto:vranganat...@hortonworks.com] >> >>>> Sent: Wednesday, 23 July 2014 1:04 PM >> >>>> To: dev@sqoop.apache.org >> >>>> Subject: Re: Final Jiras and Release Date >> >>>> >> >>>> Abe >> >>>> >> >>>> Do we want to target SQOOP-1388 also for 1.4.5 - the one that Vidya >> >>>> has raised for one of the Oracle connector export failure? >> >>>> >> >>>> My avro patch is in RB. >> >>>> >> >>>> Thanks >> >>>> >> >>>> Venkat >> >>>> >> >>>> On Tue, Jul 22, 2014 at 6:12 PM, Abraham Elmahrek <a...@cloudera.com> >> >>>> wrote: >> >>>>> Hey guys, >> >>>>> >> >>>>> It looks like we still have a couple of Jiras still open. Let's see >> >>>>> how things look tomorrow, but let's have these be the last two Jiras >> >>>>> slotted for this release. >> >>>>> >> >>>>> -Abe >> >>>>> >> >>>>> >> >>>>> On Fri, Jul 18, 2014 at 1:20 PM, Venkat Ranganathan < >> >>>>> vranganat...@hortonworks.com> wrote: >> >>>>> >> >>>>>> Sounds good. I have already uploaded the patch for SQOOP-1358. >> It >> >>>>>> needs to be reviewed by a committer and then committed if no >> >>>>>> further changes are needed (or more work needed otherwise). >> >>>>>> >> >>>>>> Thanks for driving the release! >> >>>>>> >> >>>>>> Venkat >> >>>>>> >> >>>>>> On Fri, Jul 18, 2014 at 10:58 AM, Jarek Jarcec Cecho >> >>>>>> <jar...@apache.org> >> >>>>>> wrote: >> >>>>>>> Seems reasonable to me, thank you for driving the release Abe! >> >>>>>>> >> >>>>>>> Jarcec >> >>>>>>> >> >>>>>>> On Jul 18, 2014, at 10:40 AM, Abraham Elmahrek <a...@cloudera.com> >> >>>> wrote: >> >>>>>>> >> >>>>>>>> Hey guys, >> >>>>>>>> >> >>>>>>>> I haven't seen a -1 on this suggestion. So let's create a >> >>>>>>>> release branch come Wednesday July 23rd. >> >>>>>>>> >> >>>>>>>> -Abe >> >>>>>>>> >> >>>>>>>> >> >>>>>>>> On Wed, Jul 16, 2014 at 11:38 AM, Abraham Elmahrek >> >>>>>>>> <a...@cloudera.com> >> >>>>>> wrote: >> >>>>>>>> >> >>>>>>>>> Are there any objections to this branch date? >> >>>>>>>>> >> >>>>>>>>> -Abe >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> On Mon, Jul 14, 2014 at 1:22 PM, Abraham Elmahrek >> >>>>>>>>> <a...@apache.org> >> >>>>>> wrote: >> >>>>>>>>> >> >>>>>>>>>> Hey guys, >> >>>>>>>>>> >> >>>>>>>>>> It looks like there are a couple of Jiras that are in progress >> >>>>>>>>>> and slotted for the 1.4.5 release. If we aim for July 23rd to >> >>>>>>>>>> create a >> >>>>>> release >> >>>>>>>>>> branch, does that give every one enough time to finish up what >> >>>>>>>>>> they're working on? >> >>>>>>>>>> >> >>>>>>>>>> See https://issues.apache.org/jira/browse/SQOOP-1353 for more >> >>>>>>>>>> information. >> >>>>>>>>>> >> >>>>>>>>>> -Abe >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> CONFIDENTIALITY NOTICE >> >>>>>> NOTICE: This message is intended for the use of the individual or >> >>>>>> entity to which it is addressed and may contain information that is >> >>>>>> confidential, privileged and exempt from disclosure under >> >>>>>> applicable law. If the reader of this message is not the intended >> >>>>>> recipient, you are hereby notified that any printing, copying, >> >>>>>> dissemination, distribution, disclosure or forwarding of this >> >>>>>> communication is strictly prohibited. If you have received this >> >>>>>> communication in error, please contact the sender immediately and >> >>>>>> delete it from your >> >>>> system. Thank You. >> >>>>>> >> >>>> >> >>>> -- >> >>>> CONFIDENTIALITY NOTICE >> >>>> NOTICE: This message is intended for the use of the individual or >> >>>> entity to which it is addressed and may contain information that is >> >>>> confidential, privileged and exempt from disclosure under applicable >> >>>> law. If the reader of this message is not the intended recipient, you >> >>>> are hereby notified that any printing, copying, dissemination, >> >>>> distribution, disclosure or forwarding of this communication is >> >>>> strictly prohibited. If you have received this communication in >> error, >> >>>> please contact the sender immediately and delete it from your system. >> >> Thank You. >> >>>> >> >> >> >> -- >> >> CONFIDENTIALITY NOTICE >> >> NOTICE: This message is intended for the use of the individual or >> entity to >> >> which it is addressed and may contain information that is confidential, >> >> privileged and exempt from disclosure under applicable law. If the >> reader >> >> of this message is not the intended recipient, you are hereby notified >> that >> >> any printing, copying, dissemination, distribution, disclosure or >> >> forwarding of this communication is strictly prohibited. If you have >> >> received this communication in error, please contact the sender >> immediately >> >> and delete it from your system. Thank You. >> >> >> >> >