-
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
how can I search by ip address? #28
Labels
Comments
please provide more details ... Server.search("ip:'8.8.8.8'") |
|
db: posgresql |
huh, could you please provide your |
|
schema
|
ah, ok, postgres specific datatype. search_cop currently supports text, numeric, date and boolean datatypes. I'll check if this should be extended, thx. |
thx |
Closed
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
No description provided.
The text was updated successfully, but these errors were encountered: