errose28 commented on PR #7177: URL: https://github.com/apache/ozone/pull/7177#issuecomment-2349719644
> Related to existing repair, like update TransactionInfo table as repair is risky, can cause data loss if correct value is not provided. Considering this, repair is mostly a risky operation to handle certain bug. The difference is whether the command works as the user intended. The transaction repair command will correctly update the term and index provided by the user as they intended with no unintended side effects. That is a different type of risk than this command, which may not work as the user intended. This command may silently drop fields already in the DB, either due to unintentional errors in user input or bugs in the translation path. > Repair is required for issues in current version released. This is somewhat of a contradiction. Before a release goes out we would fix all the known bugs, instead of shipping with bugs and repair tools for them together. Our current way of handling this is not bad IMO. We build the repair tools when we discover a need later, and all repair tools can be built and run from the `ozone-tools` jar independently of the rest of the cluster. Building a generic solution like this does not fully solve the problem because it is not clear how any repair should be done. That would require either very careful docs (which we aren't usually good at) or new wrappers, which would also be built from master the same as `ozone-tools` already is. > Proto3 provides better capability for proto and json conversion, But we operate on `Service object`, not proto directly. So approach followed, Our wrapper objects are for internal handling, but they are not a necessary abstraction when trying to repair the database directly, and actually get in the way. We want as few layers for things to go wrong as possible. We don't need to use these here and arguably we shouldn't. All complicated translations should be done by protobuf, which is not supported until proto 3. > So what ever data validation is present in proto builder from pojo object Or corresponding proto schema, that will happen. As I already said, schema validation and whatever ad-hoc checks we may have are not exhaustive checks that the translation happened correctly. IMO we should not implement something like this until completing proto 3 migration, which will handle the risky json translation for us. -- 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. To unsubscribe, e-mail: issues-unsubscr...@ozone.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@ozone.apache.org For additional commands, e-mail: issues-h...@ozone.apache.org
