Also, I believe this syntax should work as well with SQL we'll need to test
it out:
_query_:"{!dismax qf=myfield}how now brown cow"
Joel Bernstein
http://joelsolr.blogspot.com/
On Mon, May 23, 2016 at 2:59 AM, Joel Bernstein <joels...@gmail.com> wrote:
> I opened SOLR-9148 and added a patch to pass through filter queries.
>
> I also saw that there is one kind of geo filter that uses the Solr range
> syntax (filtering by rectangle):
>
> store:[45,-94 TO 46,-93]
>
> This should work with the current SQL interface.
>
> We should check with David Smiley and see if there are other Geo-spatial
> queries that will work with the range syntax.
>
>
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
> On Sun, May 22, 2016 at 10:30 PM, Joel Bernstein <joels...@gmail.com>
> wrote:
>
>> Actually, I just reviewed the code and it's not passing through the
>> params as I described.
>>
>> I think this is important to have working so we can support the qparser
>> plugins through filter queries. I'll create a ticket for this and work up a
>> patch for this.
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>> On Sun, May 22, 2016 at 5:16 PM, Joel Bernstein <joels...@gmail.com>
>> wrote:
>>
>>> I didn't have a chance yet to fully formulate a strategy for using the
>>> qparser plugins through the SQL interface.
>>>
>>> In the initial release there is a back door that allows you tack on any
>>> parameters you want, and they should be passed through to Solr. There are
>>> no test cases for this, but I can add some to verify this is working. The
>>> idea being that you can do this:
>>>
>>> /sql?stmt=SELECT...&fq={!geofilt ...}
>>>
>>> One of the main things I had in mind with this was allowing access
>>> control lists to be passed in, because Alfresco supports document level
>>> access control which would need to be supported through the SQL interface.
>>>
>>> But any fq should get passed through. it's not clear right now whether
>>> multiple fq's will be passed through, but due to changes that Erick
>>> Erickson recently contributed, I believe they will. Again we need test
>>> cases for this.
>>>
>>> The JDBC driver should pass through any properties that are set on the
>>> connection as well. Again I was mostly thinking about access control here
>>> but other qparsers can be added as well.
>>>
>>> This was not meant as the long term solution though. In future releases
>>> I think we should roll out as many function queries and qparser plugins as
>>> possible as SQL functions.
>>>
>>>
>>>
>>>
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/
>>>
>>> On Sun, May 22, 2016 at 3:11 PM, Timothy Potter <thelabd...@gmail.com>
>>> wrote:
>>>
>>>> How would I do something like: find all docs using a geofilt, e.g.
>>>>
>>>> SELECT title_s
>>>> FROM movielens
>>>> WHERE location_p='{!geofilt d=90 pt=37.773972,-122.431297
>>>> sfield=location_p}'
>>>>
>>>> This fails with:
>>>>
>>>> {"result-set":{"docs":[
>>>> {"EXCEPTION":"java.util.concurrent.ExecutionException:
>>>> java.io.IOException: -->
>>>>
>>>> http://ec2-54-165-55-141.compute-1.amazonaws.com:8984/solr/movielens_shard2_replica1/:Can't
>>>> parse point '{!geofilt d=90 pt=37.773972,-122.431297
>>>> sfield=location_p}' because: java.lang.NumberFormatException: For
>>>> input string: \"{!geofilt d=90
>>>> pt=37.773972\"","EOF":true,"RESPONSE_TIME":4}]}}
>>>>
>>>> In general, I wasn't able to find much about using functions with
>>>> local params in the SQL syntax?
>>>>
>>>
>>>
>>
>
