On 6/6/2022 4:55 PM, Glenn Knickerbocker wrote: > I don't get where the confusion is. W2 is the key in the master record. > If W3 in this detail record doesn't match any masters, add this record > to the reference, the same as in my pipeline with the feedback loop.
Ah, but thinking about it a little more I -do- see how in a lot of cases it could lead to confusion about why duplicate masters were added, and why masters that *aren't* duplicates *weren't* added, since records won't be selected based on uniqueness. In my application, I was looking for commented-out records matching active ones I'd already seen. The only possible match was between W3 in a commented record and W2 in an active record, so the active records were guaranteed to be added to the reference, and it didn't matter whether the commented ones were or not. Hmmm, is the duplicate master processing the whole reason for this restriction? I had never looked at output 4 of LOOKUP AUTOADD. I see that even with BEFORE I never get any duplicates out: > pipe literal x1 x2 x3 x4|split|a:lookup autoadd before 1 count > /a: /a:|cons /a: /a:|cons > 4x1 where I would if the masters were on input 2: > pipe literal x1 x2 x3 x4|split|b:not fanout|a:lookup 1 count > /a: /b:|a:|cons /a: /a:|cons > x2 > x3 > x4 > 4x1 Similarly, ALLMASTERS has no effect with AUTOADD BEFORE: > pipe literal x1 x2 x3 x4|split|a:lookup autoadd before 1 count > allmasters /a: /a:|cons > 4x1 vs. > pipe literal x1 x2 x3 x4|split|b:not fanout|a:lookup 1 count > allmasters /a: /b:|a:|cons > 4x1 > 4x2 > 4x3 > 4x4 I'd be a little surprised if this was actually a desired behavior. Regardless, too late to change now, of course, but it could be documented as applying only when the input ranges are the same, or there could be a new parameter to override it. ¬R
