Array operators #31
Labels
Comments
|
Somewhat similar to #28 Up until now search_cop tried to stay database agnostic. But, i'll check if/how we can support database specific datatypes. |
jakecraige
added a commit
to jakecraige/search_cop
that referenced
this issue
Mar 24, 2017
This commit provides a low level extension point in the hash structure to provide a lambda that returns the section of the query that is being asked for. This allows people to query for any DB types or operated that aren't directly supported in SearchCop, and SearchCop doesn't have to support them. It's a pretty low level API in that it expects you to know about what nodes and visitors are, but this seems like a starting point that gets users past being stuck, and could be built on in the future. One of those things that I think could be useful is providing this same structure, but as one of the `options` instead and that would be used every time you query for that said attribute. The downside of the method proposed in this PR is that you have to use the hash parser, and inline your SQL there and every other place you want to use it. Providing it as a default option would allow that. Related to mrkamel#31 and mrkamel#28.
jakecraige
added a commit
to jakecraige/search_cop
that referenced
this issue
Mar 24, 2017
This commit provides a low level extension point in the hash structure to provide a lambda that returns the section of the query that is being asked for. This allows people to query for any DB types or operated that aren't directly supported in SearchCop, and SearchCop doesn't have to support them. It's a pretty low level API in that it expects you to know about what nodes and visitors are, but this seems like a starting point that gets users past being stuck, and could be built on in the future. One of those things that I think could be useful is providing this same structure, but as one of the `options` instead and that would be used every time you query for that said attribute. The downside of the method proposed in this PR is that you have to use the hash parser, and inline your SQL there and every other place you want to use it. Providing it as a default option would allow that. Related to mrkamel#14, mrkamel#28 and mrkamel#31.
jakecraige
added a commit
to jakecraige/search_cop
that referenced
this issue
Apr 21, 2017
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.
jakecraige
added a commit
to jakecraige/search_cop
that referenced
this issue
Apr 21, 2017
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Thanks for a terrific gem.
If there a way to search through PG array attributes? If not, are there any plans to add support this: https://www.postgresql.org/docs/9.6/static/functions-array.html
In particular, I'm trying to use
@>operators to search through a text array.The text was updated successfully, but these errors were encountered: