-
Notifications
You must be signed in to change notification settings - Fork 343
Make bool values lowercase in solr query url - fixes #401 #435
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
Make bool values lowercase in solr query url - fixes #401 #435
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this is only used by a debug logging call, and it could be replaced by a standard dictionary get-with-default call there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This appears to be unrelated to the proposed change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would defer support for grouped responses to a larger task which would provide more help for them - just changing a log message doesn't seem to add much value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would pass a bug which encoded it as group=None or group="false".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, pysolr has avoided doing type coercion to avoid needing to know what type(s) Solr supports for a given field (e.g. a parameter like group is documented as accepting true but will also accept on or yes but not 1 or True) but I think this is relatively safe because Solr doesn't accept that value natively so the only case where this could cause a problem is if someone was passing a Solr string which they for some reason wanted to have processed literally — for example, if I had a Python app which used a Solr StringField for something and expected the literal value True or False because that field type isn't case-insensitive.
Minor changes as titled. Also added a small util function to look up nested json objects.