-
Notifications
You must be signed in to change notification settings - Fork 39
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
Support providing arbitrary SQL query generators #35
Conversation
Thx for this high quality PR! Unfortunately, I can't really imagine a use case which is worth the complexity, yet - can you give a concrete example? For me, it seems, you can accomplish similar things easily via basic ActiveRecord chaining, at least because we can't use the feature in a query string directly. MyModel.search("hello world").where("my_attribute = ?", value) I would prefer this one instead of fighting with visitors and nodes. If we could instead "mount" this into query string queries, it would be really great. |
Yep, you're totally right that adding a The reason behind this PR is that in the app I'm working on, I'm building out a generic searching functionality using what search cop provides. I have a class that returns a hash to be parsed by the hash parser which contains the entire search. The reason I went this route vs. the where is that I wanted to have one thing, search cop, handling all the searching so that if something changes in the future, I don't have to make sure to catch ever extra I could definitely work around this problem and wrap search cop in something that would handle this, but it seemed beneficial due to the references issues wanting some custom behavior as well. Another benefit of search cop providing this behavior is that it can be combined with other search cop hash params like I agree that getting into visitors and notes is pretty complex and could likely be confusing for people. I'm not totally familiar with how it all works but I figured it needed to be to make sure that it works properly when composed with other things. A simpler API could look like: Book.search({:title => {:sql => ->(attribute_name) { "#{attribute} LIKE '%Rowl%'" }}}) Would that be preferred or do you have something totally different in mind for what the API would look like? |
Yep, skipping visitors and nodes looks better to me! Two more things to add:
search_scope :search do
# ...
generator :custom_match do |column_name, raw_value|
"#{column_name} = #{quote raw_value}"
end
end
Book.search(title: { custom_match: "value" }) What do you think? |
Yeah I dig that. That was similar to one of my initial ideas, except using the Is there a particular reason you're thinking we need a new method and can't reuse that one? |
Well, search_scope :search do
attribute :title, :description
generator :custom_match do |column_name, raw_value|
"#{column_name} = #{quote raw_value}"
end
end
Book.search(title: { custom_match: "value1"} , description: { custom_match: "value2" }) Otherwise, this one would look like: search_scope :search do
attribute :title, :description
options :title, generator: -> (column_name, raw_value) { "#{column_name} = #{quote raw_value}" }
options :description, generator: -> (column_name, raw_value) { "#{column_name} = #{quote raw_value}" }
end Different opinion? |
Nope, I hadn't considered having it apply to any attribute you wanted. I like it! I'll probably be able to take a stab at this sometime in the next day or two. |
sounds great! |
2827bba
to
6a02b1c
Compare
This commit provides an extension point in the `search_scope` definition that allows you to define a named `generator` that can be used with the hash structure to perform arbitrary SQL queries. This allows people to query for any DB types or operators that aren't directly supported in SearchCop, and SearchCop doesn't have to support them. Related to mrkamel#14, mrkamel#28 and mrkamel#31.
@mrkamel PR updated with the |
search_cop 1.0.9 is out, including your patches. |
This commit provides an extension point in the
search_scope
definition thatallows you to define a named
generator
that can be used with the hashstructure to perform arbitrary SQL queries.
This allows people to query for any DB types or operators that aren't directly
supported in SearchCop, and SearchCop doesn't have to support them.
Related to #14, #28 and #31.