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? >>> >> >> >
