Yes well I was trying to avoid the lookup cascade because the reference is HUGE and is itself derived from a horribly complicated series of pipelines ... -- bc
On Thu, Aug 6, 2009 at 4:03 PM, Rob van der Heij<[email protected]> wrote: > On Thu, Aug 6, 2009 at 9:52 PM, Bob Cronin<[email protected]> wrote: >> Yes it does. So the reason for the COUNT stage is that COUNT will >> terminate when all the input records have been exhausted regardless of >> whats going on between FANINTWO and LOOKUP. Nice ... > > Which is why COUNT is not the right solution. There's a difference > between when FANINTWO consumes the record on the primary input, and > when it looks for the next record on the primary input (which happens > only after inspecting the secondary input). When the last input record > is consumed, there may still be something that must feed back into the > secondary input of FANINTWO. That's why I used the extra sentinel on > the input that is used to close the gate. > I understand this delays the record, but you have no option to do that > because of the feedback loop. > > This is not trivial plumbing. I tend to come up with solutions that > involve a cascade of lookup stages, where the unmatched detail of the > first are fed into the primary of the next, to try another match. > That's also the approach I used to match dataset names against a table > of prefixes (before the Piper gave us "floor" and "ceiling" options). > > Rob >
