zzak
zzak
This was fixed upstream, there is no need for Rails to modify the adapter now.
As @fatkodima said, the adapter is going to be removed, the gem should be the source of truth for the adapter. The adapter in Rails remains there for applications using...
If you want the old behavior, how about `raise AR::Rollback` inside the `Failure` handler? Maybe the confusion is because the initial warning didn't mention the flag being deprecated. So we...
I'm not sure what phrasing would make sense, but the thing that gets me is that we added a new flag and it was deprecated and no-op'ed in the very...
I think we can tweak this message in 7.1 branch: >To opt-in to the new behavior now and suppress this warning you can set: Open to suggestions, if you want...
> can you please brief the complexity part Rails doesn't want to introduce an API just for the sake of performance, we'd rather focus on improving the underlying performance of...
:thinking: Why not have this info for all requests? I know in large apps, finding where a request is defined can often be a multi-step and often consume more time...
Yes but I'd like to know how others feel about widening the scope of this, or if they are orthogonal.
Yeah a good way to stop Rails from inferring the `inverse_of` is to use a custom `class_name` iirc, otherwise for simple associations it does this automatically and adds the validation....
> See https://github.com/rails/rails/commit/8be1551e0b528e5d7187c793dd16da32f6043687 Does that still get the magic presence validation?