EdColeman commented on issue #914: Revert TableOps.exists() behavior. Closes #768 URL: https://github.com/apache/accumulo/pull/914#issuecomment-461990367 I think the current behavior should be classified as a bug and not something that should only be handled by documentation. With that, I think the discussion then becomes how serious a bug is it? Would I consider it a blocker for the next 1.9.x or 2.0 release, maybe not, for 2.1, probably. Because there is a work-around for the "forward" case where the table has been created, but not propagated to the cache, instead of checking for a table exits() and relying on the scanner to fail "works", but it seems like it could be an "expensive" why to check. Especially in cases where the table truly did not exist, but people keep trying to scan anyway. I do not know how to handle the reverse case where you want to make sure a table has been deleted. Even if there was a method to clear the cache, you could then test and if you didn't think the answer was what you wanted, clear the cache and retry may be a work-around rather that relying on the scanner behavior. Do you think reverting the behavior would impact performance of applications that have a relatively static configuration? Are there ways to use the znode timestamps / ids that could be used to determine if the cache is current?
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
