Dedup ALL in child query could lose rows if not fully read (e.g. if above a CHOOSEN/EXISTS)
Environment
Boca Training cluster: http://10.173.248.1:8010
Description
The following code produces different results from a SORT/DEDUP versus a DEDUP, ALL on a nested child dataset (W20170214-145408):
Conclusion
None
Activity
Show:
Gavin Halliday March 29, 2017 at 12:14 PM
Merged into 6.4, can cherry-pick into 6.2.x if required.
Gavin Halliday February 22, 2017 at 3:49 PM
Thanks
It looks like a bug in the Thor hash dedup implementation. I suspect it is not being reset correctly if all the rows haven't been read - which would be the case when it is used by exists().
I have cut down the example to a minimum. It generates the same results on hthor and roxie, but different results on thor. The sort->dedup is consistent, the hash dedup is not.
Richard Chapman February 15, 2017 at 2:42 PM
Comments?
Fixed
Pinned fields
Click on the next to a field label to start pinning.
The following code produces different results from a SORT/DEDUP versus a DEDUP, ALL on a nested child dataset (W20170214-145408):