gjacoby126 commented on pull request #901: URL: https://github.com/apache/phoenix/pull/901#issuecomment-700896096
I can see two ways to handle the case where max lookback is disabled / not supported : 1. As @kadirozde has done here, treat everything as beyond max lookback. This will let the jobs pass, but all missing / invalid rows will go into the beyond max lookback counters rather than the normal ones. 2. Treat nothing as beyond max lookback, because the concept is disabled / not supported, but change the reducer to pass the job in this case. This will put all missing / invalid rows in the normal counters. Either of these could cause user confusion. In the first case, users might wonder why everything's in the max lookback counters, and not know to look at the data more closely in case there's a real failure. In the second case, users might wonder why the job passed even though there's failed counters, and not know that some of them might be compaction artifacts from the lack of max lookback. (This might be alleviated with logging, assuming users read the logs.) Curious on what others' thoughts are, or if there's another approach I'm missing. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
