Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Remove WhereChain, and implement where_not. #9551
While the WhereChain implementation made some sense when we were
This commit removes WhereChain and implements where_not, instead. While
@carlosantoniodasilva One of these days I will remember we're maintaining the CHANGELOG more religiously now. That day was not today. Fixed.
Yeah, I hate the idea of modifying something like this late in the game, but it is a pretty simple change from a user standpoint, and cleans up the implementation quite a bit. Wish I'd had time to write this up earlier, before the beta went out.
Good instinct, @ernie. Only
@jeremy thanks for taking a look. Are you sure there isn't room for a bit more discussion on this one before closing it?
Leaving aside the discussion of whether
Back in the AR 3.x days, we supported only equality (and, for certain value types, IN/BETWEEN). There was a good deal of discussion around what a more full-featured API for creating other ARel predicates might look like, among them @lifo's SuperCondition implementation, which formed the basis for MetaWhere at the time. The suggestion at the time was that we would take a look at what plugins were developed and seemed to be most useful and at some point in the future consider selecting one for integration into core.
Here we are, 3 years later, and as best I can tell that isn't what is happening here. I haven't seen the implementation we've gone ahead with extensively tested in plugin form, but we're integrating it all the same. As such, I'm disappointed to see additional complexity in an implementation with the promise of some potential future ecosystem developing around it driving additions to core, when that has historically not been the case for the AR query API.
Given that I have skin in the game, here, I should clarify that I'm not necessarily saying that we need to implement Squeel's version of predicate building. I know it may not be for everyone. But I am saying that I built both MetaWhere and Squeel as proofs-of-concept based on the expectation that they would be included in the running for an eventual enhanced query builder API, and they have received far more real-world usage than the API we've landed on.
My last attempt at driving some discussion around this was at https://groups.google.com/d/msg/rubyonrails-core/evUmld2Mal4/PGFLjX9ZeNkJ and met with a lackluster response.
To summarize, these are the drawbacks I see with this approach at first glance: