Yes. There's always a workaround. Say you have input1 and it's a tab separated text with 3 attributes and you have another input2 in a sequence file with another 6 attributes so yes, you could run 2 map-only jobs on them to bring them to a homogeneous format with a join key indicating which part they are coming from, and then dump them together and run the final single-input job to join them.
But it's the point of a tool: you can always say you could manage to do some fire with just rubbing one wood on another instead of buying a lighter. Doesn't mean not having a lighter is a good thing for the purposes of camping. Nor it proves that lighter under new api settings works as expected :) -d On Sat, May 28, 2011 at 4:05 PM, Sean Owen <[email protected]> wrote: > You can't mix and match old and new APIs in general, no. > > It's better to use new APIs unless it would make the implementation really > hard or really slow. > > The new APIs lack MultipleInputs as of 0.20.x. That doesn't mean you can't > have multiple inputs. You can add several input paths as Shannon says. What > I don't know how to do in 0.20.x is configure a different Mapper per input > path. (Or is it true that this is an exception where you *can* use the old > API? if MultipleInputs is just setting some config variables in a certain > way that the new API respects, it works.) > > However it is *not* true that you can't know where the data is from. This is > the whole "join key" business I was alluding to last time. The key can > contain this info. (The value could, but it's more useful in the key where > it can even affect ordering.) > > Bottom line: without knowing much about what you're up to I am still 80% > sure you can construct your implementation with what the new API has. > > > On Sat, May 28, 2011 at 11:58 PM, Dmitriy Lyubimov <[email protected]>wrote: > >> As i said, and as i think Shannon's reply confirms in part, you >> sometimes can weasel your way out of this, but this is not how this >> api is intended to be used. To begin with, old and new api have never >> been intended to be used together (so you are already breaking interop >> guarantees with any of future releases), and, second, by using old api >> in part.... you are not using new anyway by definition of your >> actions. >> >> >
