-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce separate method to fail and avoid monkey patching ActiveRecord::Base #41
Comments
👍 on overall direction for modularity so people can do what they want. I don’t think I ever honestly thought people would use the enforcer stuff! Most folks run it in CI via the script in It looks like the Enforcer code has some duplication with Then some other new method could use that to assert that the problems are empty. I’d like to keep this idea as distinct from the Enforcer, since it’ll be useful in other contexts besides the “blow everything up at runtime” scenario that the Enforcer code is meant to be all about. Does all that make sense? |
That makes sense. What we didn't realize when we set this up was that this only required the database server to be started, not Rails itself. This was an error on our side because some people ran the command locally without a running database, which results in a connection error. We might revisit the way we run it, since we do actually have a running database instance in our CI runs.
Yes, thanks! I'll put up some code for you to review, but since we might also work around it by running a database server, this might take some time. Feel free to close this, too. I think the overall change is still valuable because people might've different needs, but it's definitely less urgent for us at this moment. |
Yes, agreed, please keep it open even if you don't have time. Thanks! |
We're leveraging this gem to notify developers of missing indexes during our CI runs. The way we've implemented it, is to overwrite the
mega_fail!
method inConsistencyFail::Enforcer
. This isn't ideal because this might break the implementation when new versions of this gem would be released. I'm thinking of creating a PR that introduces a separate method that fails hard instead of monkey patching theActiveRecord::Base
class, since there's no guarantee that it'll blow up in our test environment. How do others feel about this?Partial copy of our initializer:
The text was updated successfully, but these errors were encountered: