Hello could you please explain what this "Input rows count" property in tAggregateSortedRow mean? it is not documented in the UG. Thanks in advance Best regards Philippe
Many details in 2511 Summary : in tAggregateSortedRow, one output row when the input key changes. We are not aware that the current row might be the last, so the last input key is lost (we knew it, there was a warning, tExternalSortRow was adding a dummy last line to solve the problem). We have searched for a solution, and we've come to simply ask the user how many rows were expected, so that we no if the current line is the last one or not.
hello
thanks for the information.
Does tDenormalizedSortedRow work the same way? I have replaced my tAggregateSortedRow component by tDSR and the process does not work anymore (rows are getting through the component without being grouped).
thanks
Philippe
Does tDenormalizedSortedRow work the same way? I have replaced my tAggregateSortedRow component by tDSR and the process does not work anymore (rows are getting through the component without being grouped).
can you give us a data sample? (input and expected output)
Many details in 2511 We have searched for a solution, and we've come to simply ask the user how many rows were expected, so that we no if the current line is the last one or not.
I may have misunderstood, but it seems that I'm required to know how many rows are in my file before I process it. This is an unusually high burden and greatly limits the usefulness of this component. Because of the old bug, I was adding an extra row to my stream that would get dropped as the last. I guess that isn't necessary anymore, and my old algorithm is now incorrect. It's very worrisome that new versions of components are not backward compatible.
I'm using tAggregateSortedRow in a job as a workaround to a missing feature in tUniqRow. Back around version 2.3.1 I requested an option to tUniqRow to be able to keep the last row instead of the first. This was entered into bug tracker (issue id 3161), and I received several emails that different people were working on it. We're at 2.4.1 and still don't have this feature.
So now I think I'll go to plan C, and sort the data descending and then use tUniqRow to dedup.
If we put -1 as a value to number of rows then it works. is this a bug or proper? If it is proper then the entire number of rows is completely optional.
What is behavior of tAggregateSortedRow if you supply -1 as row count if it expects to know the end of the file?
